[darcs-users] How to "simulate" CVS vendor branches?

[David Roundy]

On Tue, Oct 28, 2003 at 10:35:19AM -0400, Sean Russell wrote:
> On Tuesday 28 October 2003 07:13, David Roundy wrote:
> > On Mon, Oct 27, 2003 at 09:27:09AM -0500, Sean E. Russell wrote:
> > > is any comparison.  I do find the Subversion solution to be very clean,
> > > straightforward, powerful, and elegant.
> >
> > I agree that it's elegant, but because all the branches are contained
> > in a single directory name-space, it requires that you have a
> > centralized repository.  In order to have a distributed system---in
> > particular, allowing private branches, and branches by persons with no
> > write authorization, another solution is needed.
> 
> Could you clarify that for me?  Why would it require a centralized
> repository?

Because (in the svn picture) branches are stored in the same space as files
and directories, creation of a branch corresponds to the creation of a
directory.  If you have distributed repositories, two people could create a
branch (or tag) with the same name.  This would obviously create a
conflict, but you don't want to resolve this like you would a normal
conflict.  Normally if two users try to create a directory with the same
name you probably just create one directory, and then merge the contents.
Obviously for a tag this would be totally wrong (assuming two users tag two
slightly different versions with the same tag name), in the case of a tag
you need to either disallow one of the tags, or perhaps rename one of the
tags.  I guess it would be possible to create a conflict-resolution code
that was acceptable in either case (if you don't mind the name of your tag
changing... or the tag itself being discarded), but it loses most of its
elegance.

With a centralized repository, commits are atomic, and the attempt to
create a duplicate tag can fail *when it is created*, which is perfectly
acceptable (you just try again with a different name).  With distributed
repositories, you really should avoid tag name conflicts.  In darcs this is
done by including the author and date in the tag ID, so multiple tags with
the same name are no problem, but the directory structure of svn is a
unique and small namespace (i.e. it has no hidden data like the date which
can be used to distinguish between /path/to/a/tag and /path/to/a/tag--they
are by definition the same).

> Bear with me for a second... what about distributed SCS disallow checking
> out, or submitting patches to, subdirectories?  Technically, I don't
> think DARCS could do it; DARCS keeps all of its metadata in the top-level
> directory, whereas something like CVS and Subversion keep metadata in
> each directory.  That's just a design decision, but it doesn't have
> anything to do with whether a repository is centralized or distributed,
> as far as I can see.

The difficulty here is that renames are by definition not limited to a
subdirectory, so every copy of the repository will still need to have every
subdirectory unless you restrict the movement of files and directories.

> Now, the way Subversion does branches and tags would be difficult to migrate 
> to DARCS, because SVN's mechanism is "light".  That is, a copy is just a link 
> to a particular version of the repository. If you copy an entire directory 
> tree, it costs no more than a few bytes for the link.  If you change 
> something in the tree, all that gets stored is the diff.  I don't know how 
> this could translate to DARCS.

In darcs there is no copy, which is because of the requirement that patches
be invertible--not that it is impossible, but just confusing.  The
inversion of a copy is obviously a merge of two identical files.  So then
the question becomes how hunk patches will commute with a copy--and how
they will commute with the merge, which is determined by how they will
commute with the copy.

Hmmm.  If I have C(AB) copies A to B and H(A) is a hunk patch on file A, then

C(AB) H(A) <---> {H(A)H(B)} C(AB)

where {} indicates what I call a split patch--it means that the two patches
must commute together.

The problem is in going the other way

H'(B) C(AB) <---> ?

These obviously wouldn't commute--the commutation with hunks is essentially
only in one direction (which is why the result is a split patch rather than
simple hunks).

Anyhow, it can get complicated, and if a patch type doesn't commute then
its only benefit is in reducing repository size, which generally isn't
worth it in my opinion (unless, of course, you do things svn's way and
require copies for branches and tags).
-- 
David Roundy
http://www.abridgegame.org