--- Dave Rolsky <autarch@urth.org> wrote:
> ---------- Forwarded message ----------
> a nuisance. If I
> were to prioritize features for a CVS replacement on
> a scale of 1 to
> 10, they'd go:
>
> Repeated merges - 9
> History across renames - 6
> Speed and atomicity, etc - 2
I pretty much agree except for the atomicity part. I
can only trust stuff I get from CVS 99% since I'm not
sure if I got a partial checkin when I do a checkout.
> That is to say, renames are a minor pain, but not
> worth switching for,
> but better merge support is critical. Switching
> before the support's
> in place means any benefits to faster branching and
> tagging are
> irrelevant because it's too much trouble to maintain
> lots of branches.
Constant-time tagging may be enough for some shops to
switch. I agree that constant-time branching would be
worth much more once Subversion supports merge
history.
> I'm rather disappointed to see that svn wants to
> save it for post-1.0.
I'm a bit disappointed as well. OTOH, I can't
complain too much since I'm not helping in this
endeavor either.
> Once that works, remote repositories aren't too much
> harder. You've
> got clone (make a new branch, except on a remote
> machine), and
> push/pull (which are merges).
This is a neat idea. OTOH, unless BDB supports
distribution like this, I think it won't work.
> You have to embed
> enough data in the
> metadata to locate the most recent common ancestor,
> which means adding
> something like
> user@host%clone-source/uniq-id-from-clone-source to
> the
> labels of clone branches, and pulling in the minimum
> clone history of
> remote files when you merge them. This second part
> is a little tricky.
If the design documentation is any indication of how
it will be done, as I understand it, Subversion will
keep track of what revisions comprise a version so,
when a remerge occurs, Subversion will know what's
already been merged and not do it again. It sounds
similar to remembering ancestors, but the finer
granularity means that you can leave out a revision on
a branch during the first merge, then later the
remerge can still pull it in provided you don't leave
it out again.
Can the experts confirm my description and whether
it's still the proposed solution?
Thanks,
Noel
__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 19 01:09:11 2002