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 :-}
_______________________________________________
Monotone-devel mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/monotone-devel
