Re: [Monotone-devel] Future of monotone

[Ethan Blanton]

Daniel Carosone spake unto us the following wisdom:
> [slowly working through a big mail backlog]
> 
> On Mon, Jan 28, 2008 at 12:17:54PM -0500, Ethan Blanton wrote:
> > 5) Workspace merge.  This was started, but never finished.
> >    3-way-merge tools are all well and good, but sometimes the Right
> >    Answer is just a developer in an editor.  I see a lot of grumbling
> >    about this on our chat channels and mailing list.  Extremely large
> >    merges are particularly annoying, because they have to be handled
> >    in monotone's preferred order, the context around changes is hard
> >    to find (e.g., you don't know what another, successfully
> >    auto-merged file looks like, because you can't reference the
> >    merge-in-progress until it's done), and they have to be completed
> >    all in one shot without any failures.
> 
> While this is clearly a matter of preference and past expectations,
> and I can certainly understand the desire for this at least some
> times, I maintain my belief that ZipperMerge is in general the better
> practice to deal with large complex merges -- even if and when
> workspace merge is available at each step of the Zipper..

I agree that zipper merge helps, and we certainly use it.  But we *do*
use lots of feature development branches (as you mention), and some of
them are for Big Changes which are rather long-lived.  If one does not
keep on top of merging of those branches, they rapidly become quite
difficult to merge, zipper merge or not.  I really view Daggy
practices in general as somewhat orthogonal to workspace merge --
workspace merge simply gives the developer more context for the
changes, and the freedom to merge files and hunks in any order that
seems pleasing at the time.  The current status gives very little
context without (multiple, sometimes complicated) external workspace
manipulations, and enforces an artificial and arbitrary ordering on
conflict resolution.  While human brains may alos by arbitrary,
sometimes tackling in a less arbitrary order makes the process
cognitively simpler.  ;-)

> Good use of DaggyFixes, lots of feature development branches, and
> other practices that exploit the DAG to its best effect help
> immensely to avoid tangled merges.

Agreed.  These only go so far, though.  (Feature development branches
somewhat exacerbate the problem, even.)

> Yes, you can wind up with lots of workspaces for different purposes,
> but personally I don't find that so hard or complex as some of the
> intra-workspace features (pushing and popping patch sets?) suggestions
> seem to be.

I personally adopted lots-of-workspaces under OpenCM, and it doesn't
bother me.  It's not really at issue here.

> UI and tools that help and encourage these practices would of course
> be very valuable.

UI tools could definitely make workspace merge less necessary, but the
only way I see for this to be the case is to have UI tools which
simulate large parts of workspace merge.  I think just doing the real
thing is easier, and has more benefits than the tools.  ;-)

Ethan

-- 
The laws that forbid the carrying of arms are laws [that have no remedy
for evils].  They disarm only those who are neither inclined nor
determined to commit crimes.
                -- Cesare Beccaria, "On Crimes and Punishments", 1764

signature.asc
Description: Digital signature