[darcs-users] Branching, again, in more detail

[David Roundy]

On Wed, Nov 19, 2003 at 07:15:38PM -0800, Kevin Smith wrote:
...
> But the changes I make in 1.01 seem to be stuck in that repository. When 
> I want to make a backup copy of "all my source code" for this project, I 
> have to back up both repositories. If I publish my repository on the 
> web, it would have two URL's. There doesn't seem to be any way to have a 
> single repository (directory tree) that contains all the patches for 
> both 1.01 and 2.0.

This is indeed the darcs way of doing things, with each branch getting its
own repository.  Having two URLs doesn't seem so bad to me.  If you didn't
have two URLs, you'd just have to have an extra flag to give to darcs to
select the branch you want.  If you're concerned about disk space for
backing up (assuming your backup program can't take advantage of the hard
links), you could use darcs get --partial (which is still experimental, so
at the moment you'd want to do this with a copy) to create a repository
that has only the changes between 1.0 and 1.01.

CVS supports branches internally.  Subversion doesn't support branches (as
branches), but allows you to represent them using cheap directory copy
operations *within* a repository.  Darcs allows you to create branches
using expensive directory copy operations *outside* the repository
(possibly less expensive due to hard links).  You lose something in disk
space the darcs way, but you gain flexibility.  As you say, you have to
keep both repos if you want to keep both branches, but on the plus side, if
you don't want to keep a branch, you can throw it away, which is something
you can't do with CVS or subversion.  Or if you want to create a branch of
a repository to which you don't have write access...

> Oh, wait. I could create a tree and pull 1.01 from the new repository, 
> then pull 1.0, and then 2.0 from the 2.0 repository. This new repository 
> would have all three tags, so I could pull 1.0, 1.01, or 2.0 from it 
> into yet ANOTHER repository at any time in the future.

This would work.  It would be probably be *very* slow, since you'd have
conflicts galore, and massive amounts of commuting to do every time a patch
is added.  I don't recommend it, but if you did try such a thing, you'd
definitely want to use apply --no-resolve-conflicts to add the patches.

I've recently been thinking about a related idea which may solve some of
this awkwardness.  One thing that darcs can't really do currently is
support cryptographic signing of patches.  I do use it for pushing, but
that's a patch bundle.  Patches in a repository tend to get changed due to
merges and commutes of various sorts, so any signature would be likely to
soon be invalid.

One way around this would be to store "patch bundles" rather than patches.
A patch bundle holds one or more patches as well as the context of the
patches (identified by a set of patches).  As long as you tag reasonably
often, patch bundles aren't too much bigger than the patches themselves.
The patch bundles could be signed (and possibly resigned by more than one
person), so people could verify that they are looking at the "real thing".

We wouldn't want to use patch bundles for ordinary working repos, since
they would be much slower to work with than normal ordered patches, since
you'd have to do a lot of commuting to get them into workin order.
However, as a "reference" repository, it would be fine.  Since they
wouldn't be held in sequence, this would also solve your issue of wanting a
single place to hold all your branches.

I don't expect to create this "bundle repository" any time soon.  Mostly
I've been thinking about it because I want to know that it can be done--if
there is a fundamental limitation on what darcs can do, I want to know it.
But it really shouldn't be all that hard, since darcs can already create
bundles.  Of course, the bundles would probably have to contain single
patches, and be named using the hash scheme.  The thing that is missing is
the ability to "pull" from such a bundle repo, but even that wouldn't be
too hard, since we already have apply.  The missing feature would be that
if the user wants to pull a patch whose context we don't have, we'd have to
go get the context first.
-- 
David Roundy
http://www.abridgegame.org