D 2010-02-12T08:12:42
L Branching
P 5e7037ebbc230c4b987a7c4de9e18782f1a68035
U eric
W 4277
Fossil's support for branching was revised in January 2009. Since then the best thing to do is:
<ol>
<li>Read the
[/doc/tip/www/branching.wiki|embedded tutorial on branching].</li>
<li>Read the [/doc/tip/www/faq.wiki|FAQ] entry on branching.</li>
</ol>
Some of what is below the line is now wrong or irrelevant.
<hr>
We probably need some notes on branching.
For now, here is a response to ticket [f90265fc83]:
# create testing branch<br>
fossil tag branch testing <i>uuid1</i>
# where <i>uuid1</i> is the point at which you want to branch<br>
# Note that the above command creates a new checkin which is a<br>
# sibling of <i>uuid1</i> and identical to it.<br>
# You still need to tell fossil to use it in the working directory<br>
fossil update testing<br>
# do some experimental work<br>
...<br>
# back to main branch<br>
fossil update <i>uuid1</i><br>
fossil update<br>
# The second update is needed because the main branch may have<br>
# moved on from <i>uuid1</i>.
Note that fossil has no concept of a default branch, and in the presence of multiple forks and branches you are usually safer to give an explicit argument to <b>fossil update</b>.
Because fossil supports distributed operation, forks which are not deliberate branches can be quite common, and there is probably no safe algorithm for "the latest non-branch UUID".
<hr><div id="6f02643c22ea3612"><i>On 2008-10-19 14:52:08 UTC anonymous added:</i><br />
Here is an example of branches work with mercurial<br>
<br>
# switch to testing branch<br>
hg branch testing<br>
... do some commits<br>
<br>
# switch to default branch<br>
hg branch default<br>
... do another commits<br>
<br>
# continue testing work<br>
hg branch testing<br>
<br>
But with fossil i need to use UUID? How can i automate this work?
... commits</div id="6f02643c22ea3612">
<hr><div id="9b139c0ef4c84e4e"><i>On 2008-10-19 15:44:45 UTC eric added:</i><br />
But if you could say<br>
fossil tag branch testing
what should the branch be based on? Your current checkout? The latest descendant of your current checkout? The latest checkin in the "main branch"? Which should it default to? Should fossil sync with the central repository first, if there is one and if your local fossil knows what it is?
If you want to start from the head of the "main branch", or any branch, what if there is an unintended fork there cause by someone syncing a local repository? If there is should you require a merge?
I think you can only answer these questions based on some single view of the change process that suits your situation. If you know what you will always do, you can write a wrapper for fossil in you favourite scripting language.
For instance (and only by way of example) branching based on the current checkout can be done by
<code>
fossil tag branch testing `fossil info|sed -n '/checkout: */s///p'`<br>
</code>
As for going back to the main branch, there is nothing stopping you from tagging that with the name "default", though the best time to do it is when you create a new repository. And that doesn't solve the problem of which fork to choose, or does it mean going back to where <b>you</b> were on that branch?</div id="9b139c0ef4c84e4e">
<hr><div id="e127db481c42b864"><i>On 2008-10-20 09:40:04 UTC anonymous added:</i><br />
And after that fossil is "ridiculously easy to install and operate"?? Mercurial (and even git!) is much easier to use. (At least in branching and local sync)</div id="e127db481c42b864">
<hr><div id="a8ffc89a461d52f0"><i>On 2008-10-22 19:50:33 UTC eric added:</i><br />
Yes, it is. Branching is complicated, books have been written about it
(e.g. [http://www.amazon.com/Software-Configuration-Management-Patterns-Integration/dp/0201741172/ref=pd_bbs_1?ie=UTF8&s=books&qid=1224704449&sr=8-1|SCM Patterns]).
I think you have to ask similar questions whatever tool you use. If you find one that defaults to your answers, good - but how much work will it be next year when you have different answers?
I assume you are not falling into the trap of expecting all SCM tools to work in exactly the same way. The world doesn't need another clone, it needs a different approach.</div id="a8ffc89a461d52f0">
Z 606d4abd5bfad211bc3c55b0278229d6