[Rivet] Branched release-2-0

[David Grellscheid]

Hi Frank,

>> Also, hg pull cannot selectively pick individual changesets. You always get
>> the full tree leading up to that point. That would mean that pulling default
>> into release-2-0 brings _all_ of default in. That's not the behaviour you
>> usually want.
>
> Aaah, that explains it! Then of course it's clear that new analyses
> and bugfixes have to go into the release branch. I thought it works
> similarly to how I used SVN: put the new feature into trunk and then
> merge it into a branch if wanted. Is such a workflow completely
> impossible/disfavoured in hg?

It's unusual. Because merging is so extremely easy, there is no reason 
to develop independent features at the same time on trunk. Trunk becomes 
a holding area for _ready_ features, that are waiting to be released. 
For any actual development, you would create a clone of trunk into 
private/foo and develop it there [1].

For diffrent feature developments, clone trunk to private/bar and 
private/baz.

Now what do you do if you want to develop yet another feature qux, that 
depends on foo and bar? If this following workflow clicks, it all should 
make sense :-)

####################################

On hepforge:  hg clone ...public/trunk ...private/qux

Locally:

hg clone ssh://....../qux workdir; cd workdir
hg pull ssh:///....../foo
hg merge
hg ci
hg pull ssh://....../bar
hg merge
hg ci

... start developing qux stuff ...

hg push # (goes to qux)

... new bar stuff arrived ...

hg pull bar
hg merge
hg ci

... develop qux more ...

... qux is ready ...

hg push # (goes to qux)
hg push trunk # (goes to trunk)

... tada! trunk now has qux (and foo and bar) ...

############################


To allow this mix-and-match of developing features it is vital to keep 
them in orthogonal clones while they are still in flux.


#####################
Want to know if features foo and baz can work together?
$  hg clone foo workdir; cd workdir; hg pull baz; hg merge
#####################

Once a feature is stabilized, push it to trunk, and remove it from 
private (I usually archive them somewhere). All other feature branches 
will then pick up the new stable feature the next time they pull trunk.

It's much easier to explain with a blackboard :-D

See you,

   David




[1] It's better to _not_ give these clones in private a 'hg branch' 
name, since they'll be re-integrated into trunk eventually. They are 
distinguished by where their central copy lives.

Technically, not having a branch name is what allows the plain 'hg 
merge' in the examples above to work. Otherwise, you'd have to 
explicitly specify the name each time.