monotone-devel
[Top][All Lists]
Advanced

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

Re: [Monotone-devel] Future of monotone


From: Daniel Carosone
Subject: Re: [Monotone-devel] Future of monotone
Date: Sat, 2 Feb 2008 18:23:34 +1100
User-agent: Mutt/1.5.17 (2007-11-01)

[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..

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.

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.

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

--
Dan.

Attachment: pgpZ9azYC4RtT.pgp
Description: PGP signature


reply via email to

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