[darcs-users] Branching, again, in more detail
aoiko at cc.ece.ntua.gr
Thu Nov 20 04:16:26 UTC 2003
On Thursday 20 November 2003 05:15, Kevin Smith wrote:
> I'm still struggling with how I would do branching with darcs on an
> actual project. Specifically, I'm interested in going back to create a
> 1.01 version when I am close to releasing 2.0. For simplicity, I will
> assume that the changes I make in 1.01 do not apply in the 2.0 tree, and
> that I do not want to pull anything from 2.0 back into 1.01.
> In a conventional RCS, I would have a single repository that has the
> mainline (head) which is my work toward 2.0. Then, I would also have a
> branch for my 1.01 development, which forked at the 1.0 tag.
> With darcs, I can see that I could create a new (empty) 1.01 repository,
> and get or pull the 1.0 tag into it from the old repository. I can work
> on 1.01 and 2.0 simultaneously, in different directories.
> 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.
That's fugly. Not to mention inflexible (you'd have two URLs anyway, unless
you expect people to always work with the whole repository). But don't listen
to me, past experience with the FreeBSD cvs repository still haunts me :)
> 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.
I don't think this fits well in the darcs model (or that it would work for
> But if I want to do more work on 1.01, I would have to repeat the whole
> process, except that I would start from the 1.01 tag this time.
> That seems fairly inconvenient from a source code management standpoint.
> Is it just something to live with, or have I overlooked a solution? Or
> is is something that could be done within darcs but just hasn't been
> implemented yet?
> Which reminds me: What is the undocumented 'inventories' directory for?
Do a 'darcs tag' before you look in it, then it should be obvious.
 which was at 1.7GB when I lost it along with a disk. Lots of branches,
lots of tags, terribly slow and a mess to work with.
More information about the darcs-users