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

Kevin Smith yarcs at qualitycode.com
Thu Nov 20 17:02:39 UTC 2003

Peter Simons wrote:
> Okay, I think I have figured it out. Here is the inofficial
>     Branching with Darcs Guide

Thanks! This is helpful for two of the three common branching needs that 
I know about. This seems like another example of material that would be 
handy to put on a darcs wiki. David: Do you have any interest in wikis? 
Would someone on the list be willing to put one up?

In this branching guide, point number 2 is what I would call a 
"development branch", where a developer needs to work on a long project 
without messing up the main line code. When that work is finished, the 
expectation is that the two branches will fully merge, and the temporary 
branch will go away.

In reality, the developer may keep his branch open and start working on 
something else, but conceptually he has really started a new branch at 
that point. If the branch persists, it really seems more like a vendor 
branch than a development branch. With darcs, the distinction between 
the two is not completely clear.

Your point number 3 describing "vendor branches" makes a lot of sense. 
It is clean and simple. I like it. This kind of branch would typically 
persist forever.

Another branch type is a "legacy version fix branch". In this case, you 
need to go back and fix a critical bug in an earlier version, without 
disturbing your current main line code. The legacy branch should be a 
"dead end" branch, meaning it will exist forever, but at some point 
(hopefully very soon) it will stop being updated.

This "legacy" branch is the only one that I personally need on a regular 
basis, and unfortunately it is the one with the least support from 
darcs. However, I am ok with my understanding of how it works. It's not 
ideal, but it seems workable.

Here is what I would propose adding to your unofficial darcs branching 

4. Legacy Version Fix Branching

Let's say we need to create a 1.0.1 version based on the 1.0 release. 
Create a new repo by using 'get' to pull the 1.0 tag from the main 
repository. Do your 1.0.1 work in this repo, while continuing to do your 
main line work in the main repo. You can push or pull individual patches 
back and forth between the two repos.

Compared to "conventional" RCS systems, having two completely 
independent repos has advantages and disadvantages. As with any darcs 
repository, you can work on this one offline. Also, it is easier to 
intentionally throw away your branch with darcs if you wish. On the 
downside, it puts more of a burden on you to manage two separate 
repositories, such as for backups or making repos available publicly.

Often, the darcs approach requires more disk space, because you have two 
full copies of all the patches that led up to version 1.0. There is no 
clean solution to this, although there are workarounds.


More information about the darcs-users mailing list