Re: distributed repositories via branches (fwd)

[Dave Rolsky <au...@urth.org>]

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 <ox...@waste.org>
To: Dave Rolsky <au...@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

Re: distributed repositories via branches (fwd)

[Dave Rolsky <au...@urth.org>]

[ Please keep in mind that I'm responding to a reponse to a message I
forwarded, not one I wrote ... ]

On Fri, 18 Oct 2002, Noel Yap wrote:

> > 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.

I don't think there needs to be BDB support for this.  As long as their is
DAV support to get the required data, that should handle it.  Push and
pull are basically checkin and checkout.


-dave

/*==================
www.urth.org
we await the New Sun
==================*/


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: distributed repositories via branches (fwd)

[Noel Yap <ya...@yahoo.com>]

--- Dave Rolsky <au...@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