|Subject:||Re: [Monotone-devel] Best practice using monotone|
|Date:||Thu, 24 Aug 2006 15:30:11 +0100|
Andy Jones wrote:
> 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...
http://www.venge.net/monotone/wiki/BranchRenaming explains it, it is
some what of a hack.
> === 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
> === Release Branch Pattern
> Hmm. Is your "deliverables" branch a release branch, or is it a fifth
> 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
> 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?
Correct, monotone has no such problems. If you try to pluck the same
thing twice it will try to do the previous merge again, but if you
propagate or explicit_merge it know how to handle data you already
merged. This is one of the reasons I like monotone over SVN.
|[Prev in Thread]||Current Thread||[Next in Thread]|