This is brilliant, thanks.
Some stupid questions (the best kind):
Monotone doesn't care what branches are called, and you can rename
branches later on.
Err, how do you do that? You mentioned kill_branch_certs_locally...
=== Vendor Branch Pattern
So to my way of thinking we have vendor branches, working branches, and
release branches. And we also have - what would you call them? "fork"
branches, as in the "muffins" example from the tutorial.
While these are really all the same animal they should be thought about
in different ways. I guess you are already saying that by calling them
patterns.
=== Release Branch Pattern
Hmm. Is your "deliverables" branch a release branch, or is it a fifth
animal?
BTW are you really saying that you can rename a file in the deliverables
branch, merge it back with the working branch (at which point the name
magically changes back), change it, propogate back into the deliverables
branch, at which point the name changes back +again+? Good grief. Even
if CVS had a rename command, doing all that would cost most developers
half a day and two near heart-attacks. Think of all those merge tags...!
Don't group many changes together into a single commit. Do a commit for
each logical change. This makes it easier for others to "pluck" or
cherry pick
only the changes they are interested in.
For example, commit bug fixes and feature enhancements separately.
Should feature enhancements have a seperate branch? Or, one branch per
enhancement? How many branches is too many?
This very point is why I'm glad to see the "pluck" command. In my job,
I make a lot of little fixes ...
I see that it's normal at Venge.net <http://Venge.net> to use tags
within the working branch to mark releases. It seems to me that that
would be redundant if you used your "deliverables" branch pattern,
because it would later become the release branch. The start of the
branch would always point to the start of the release - or am I missing
something?
In CVS of course it's de rigeur to tag the point where you fork a
branch. I can't work out how (in Monotone) you would select the start
of a branch otherwise, so I suppose it's still needed. Unless of course
you never needed to refer back to the start of a branch...
There are some nasty cases in CVS where if you repeatedly merge one
branch with another, Bad Things Happen. Because the common ancestor is
still the same, CVS tries to do the previous merge a second time. I
take it Monotone has no such problems?