[darcs-users] Re: Branching, again, in more detail
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
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