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. _______________________________________________ Monotone-devel mailing list Monotoneemail@example.com http://lists.nongnu.org/mailman/listinfo/monotone-devel