Re: [Monotone-devel] Question on layering

[William Uther]

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 directory
> > there, "mtn/".  That would hold a n.v.m.dumb tree.  The tricky  
> > part is
> > also looking for changes in trunk/ since the last change to mtn/ and
> > moving 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  
> > normal
> > client 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.)  
> and
> might 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       :-}