My friend said I could forward this if I pointed out that he assumes that
the developers already know some or all of what he's saying below.
For those who don't know it, it might be interested. This is a follow-up
to the thread from earlier about changesets and distributed repositories.
-dave
---------- Forwarded message ----------
Date: Fri, 18 Oct 2002 17:25:56 -0500
From: Oliver Xymoron <oxymoron@waste.org>
To: Dave Rolsky <autarch@urth.org>
Subject: Re: distributed repositories via branches
On Fri, Oct 18, 2002 at 03:58:08PM -0500, Dave Rolsky wrote:
>
> So if you're asking can you branch from branches, the answer is yes.
No, I'm asking if you can do
A
|\
| \
A2 B branch off a feature
| |
A3 B2 parallel development
| /|
A4 | merge changes
| |
A5 B3 more parallel development (CVS does everything up to here fine)
| /
A6 the repeated merge
CVS goes back and basically tries to merge all changes A->B3 into A6,
which conflicts with the last merge. What you really need to do is
merge B2->B3 into A6, recognizing that it's the most recent common
ancestor, but CVS doesn't remember both parents of a merge. You can
manually tell CVS what tag to merge from, but that's 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
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.
I'm rather disappointed to see that svn wants to save it for post-1.0.
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). 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.
Consider:
A B C (users)
A0 A creates project
|----\
| C1 C clones A
A1 | A modifies
| /-|
| B1 | B clones C
A2 | | A modifes
|--+-\|
| | C2 C pulls some or all of A's changes A0->A2
| | C3 C modifies
| |/-|
| B2 | B pulls some of C's changes C1->C3
| | |
| B3 | B modifies
|/-| |
A3 | | A pulls all changes A2->B3, which means B needed to get a history
| | | of pulls from C when it did B2
The minimum to store for each pull is the nearest common ancestor
in each known repository. The clone/pull graph is a proper subset of
the branch/merge graph.
Then there's the whole issue of changesets..
--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 19 00:39:19 2002