[Rivet] General HG points

[David Grellscheid]

Hi all,

let me just clarify a few points. First, the nomenclature. The basic 
unit of transaction is a changeset, uniquely identified by its 
hexadecimal hash. Pull and push moves whole changesets between repos, 
including their prerequisite history. If a changeset already exists, it 
will not be pushed/pulled again.

Every clone is automatically also a branch. When you bring two branches 
together with pull or push, they may end up with several heads or not. 
Heads are the leaf nodes in the tree of commits. The only way to reduce 
the number of heads is an explicit "merge" followed by a commit.

Cloning is cheap in terms of resource usage and maintenance overhead, 
there is no reason to avoid clones. Clones on the same disk don't even 
copy any files.

HG offers a feature called "named branches". It should not be used 
extensively, as there is no way of ever getting rid of a named branch 
again. You also lose a lot of flexibility that the normal branching 
system gives you. The only situation where named branches are useful is 
for parallel versions of the code that will never become unified, but 
which need to be kept in some form of synchronization. E.g. release vs. 
development; aida vs. yoda.

The procedure for new features that will eventually become part of the 
core stays the following:

Clone from trunk, develop until ready, pulling regularly from trunk. 
Only when ready and approved, push to trunk. Never develop two things on 
the same clone. This can happen purely on your private machine,
but the hg-private area is intended as an optional central backup 
location to pull / push from. Especially when several developers need 
access to a new feature branch, it should be on hg-private. All Rivet 
members have access there.


One-line summary: Nobody pushes directly to /rivet without first testing 
what will happen.


> Having a clear statement on when to use clonesand when to
> use branches(and why!) would be pretty useful to me.

Clones: always, 5 times a day, the more the better.
Named branches: never

Main reason: clutter. You would eventually accumulate branch tags for 
every single feature you'd ever developed.

> In fact, if we want to freeze development for 2.0.0 then would it
> make sense if there was a 2.0.0 release candidate branch

No, not an RC branch. The branch should be made the moment that the 
release happens. Note that this is not a feature branch, but a release 
track, so that bugfixes can be applied cleanly. Trunk then pulls 
regularly from release-2. However, release-2 must NEVER pull from trunk 
again after it's been created.

This last point is the reason why candidate branches are not a good 
idea. Once you've branched, you can't cherrypick some future trunk 
changes over others. You either take them all or none of them. That's 
why the trunk itself needs to be the candidate up until the release point.

Feature branches don't need to live very long. Something like "Clone, 
develop, merge back 2 days later" is no problem at all, but you have the 
guarantee that trunk either has the new feature or it doesn't and is not 
left in a half-way state. Once a feature is merged back, all other 
feature branches obtain it the next time they do a pull from trunk.



Summary: The dangerous operation is "push to trunk". Check carefully! 
Everything else is fixable.



See you,

   David