monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] Best practice using monotone


From: Andy Jones
Subject: Re: [Monotone-devel] Best practice using monotone
Date: Thu, 24 Aug 2006 10:35:40 +0100

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 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?

Andy.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]