Re: [Monotone-devel] Best practice using monotone

[Andy Jones]

Okay, only one more dumb question that I can think of:  is there a doc somewhere that explains how the trust / quality assurance model works?  

The brief description in the manual takes things from a technical standpoint, rather than a functional one.  I think I have a pretty good idea what the tools are: five lua hooks, and the commands approve, dissaprove, and testresult.  But I'm not sure of the best way to put these together, or what to use them for.

For example, for release control: would/could you use them to produce a working area which was linked to a release, like CVS' "sticky" checkouts?   (It seems to me that you could do this, but it would need its own dumb server...)

Or: is it better to arrange that there is always a branch, the head of which corresponds to each release?  (Which would seem more limiting.)

Maybe a simpler question would be: what are the differences between the two approaches - (1) using mtn approve (2) using mtn testresult.

Thanks again,
Andy.

On 24/08/06, Matthew Nicholson <address@hidden> wrote:

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

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.

--
Matthew Nicholson
matt-land.com