|
From: | William Uther |
Subject: | Re: [Monotone-devel] Question on layering |
Date: | Wed, 21 Feb 2007 11:20:01 +1100 |
On 21/02/2007, at 10:56 AM, Christof Petig wrote:
William Uther schrieb:iv) A normal subversion server has a fixed directory layout with"branches/", "tags/" and "trunk/". If you link with the svn libraries,then you could use them to access the server, add another directorythere, "mtn/". That would hold a n.v.m.dumb tree. The tricky part isalso looking for changes in trunk/ since the last change to mtn/ andmoving them across into the mtn/ repository. It wouldn't be too hard in a special program, like mtn_cvs, but you'd really want it in the normalclient so that changes would be synced with every sync :).I would recommend the contrary: mtn_cvs has worked well so far and uses a well defined abstraction to interface both VCSs. Integrating more and more into a giant mtn binary is not a good idea, git doesn't do it either.
Fair enough. Done that way you also require either a) a cron job to do the syncing between systems, or b) hooks on each system to trigger syncing.
vi) There is a partial-pull branch, but it looks like it has just started. It also seems from the wiki that the concept is more "partial-pull once and lose history" rather than "use a local db as a cache for a remote db", but I may have misunderstood. I prefer the "hierarchy of caches" approach.We prefer to start with manual horizon movement (pulling more etc.) andmight go further once it is proven to work. Seeing "unknown" in annotate/log is not that bad for a first start.
I agree that "unknown" isn't bad to start. But it seems like you're having to solve a bunch of problems with missing data. I'd do it the other way around. Of course, I'm not the one doing it :), so please ignore me.
If I were to get around to patches for missing-data fallback (unlikely, but you never know), would they be accepted?
Unfortunately mtn_cvs, mtn_svn, mtn_git and partial pull all simultaneously compete for my spare time :-(
Fair enough. If I had to rate these in terms of general importance, I'd put partial pull first, mtn_svn next, mtn_git next, and mtn_cvs last. Specific importance is different because I'm using mtn_cvs at the moment, but that is only until I can convince some others to dump cvs.
Partial pull is important for first-user impressions. People checking out source don't want to download the entire repos. mtn_svn is next most important because it allows interaction with sourceforge projects.
Any help on any of these is of course greatly appreciated.
I'll send you my mtn_cvs tests soon. Will :-}
[Prev in Thread] | Current Thread | [Next in Thread] |