Re: [Monotone-devel] Commit a child of 2 parents

[Yury Polyanskiy]

but propagate from devel to mainline still suffers from lack of
merge-via-working-dir as you say. 

It was really a shock to me when after so much excitement about the
design of monotone I found that once I had a merge conflict I CAN NOT
hit exit and fix everything in the tree myself (ensuring that it
compiles and works as follows before doing a real commit). 

On Tue, 2006-01-17 at 11:04 +1100, Daniel Carosone wrote:
> On Mon, Jan 16, 2006 at 06:25:08PM -0500, Ethan Blanton wrote:
> > Generally speaking, this is a very reasonable thing to do. 
> 
> Agreed on all points, including the fact that merge-via-working-dir
> will need to handle such cases.
> 
> My comments were related to current monotone, which doesn't have a way
> to create such a graph; this hasn't been an issue so far, for the
> reasons you outline.
> 
> However, I do like the 'cleanliness' of the present model, whereby
> merges are fairly minimal (usually entirely trivial) changes.  Maybe
> its more a matter of 'best practice' rather than a strict VCS
> functionality issue, but in general I prefer that the work for the
> kinds of changes you're talking about are done as separate commits in
> preparation, such that the actual merge doesn't contain much work.
> One reason for this is so that repeated merges/propagates between
> development lines is easier.
> 
> As another way to illustrate, in present monotone development the
> kinds of issues you raise are often handled by multiple propagates
> from the mainline to the development branch along the life of the
> development branch, before a final "put back" propagate from
> development to mainline (or any other similar pair of branches).  Your
> description seems to assume a development practice where the branches
> diverge just once at the start, and all parallel changes are merged
> once at the end.
> 
> --
> Dan.