Re: [Monotone-devel] Automerging

[Rob Schoening]

Actually I run into your option 1 problem fairly often, particularly with configuration files.

 

The solution that would be most helpful to me is actually pretty simple:

 

If there was a ".mtn-ignore-commit" file that prevented matched files from being committed, I think that would eliminate most of my problems.  Or, alternately, if mtn just refused to commit a file that was in .mtn-ignore just as it does with add, that might be sufficient.

RS
 

On 5/22/07, William Uther <address@hidden> wrote:

Hi all,

  I thought I'd throw out another wacky idea...  I've been mulling
this one for a while, but a post by Stéphane Gimenez in the Branches
in git and monotone was close enough that I thought I'd bring it up...

  There are a number of situations where I have local patches to a
program.  I'm also actively developing that program.  And my local
patches are not acceptable upstream.

  As things stand it is annoying to develop in this situation.

  Option i) I could just leave my patches uncommitted locally.  I
only commit the things I want to go upstream.  This is annoying
because I keep accidentally committing my local changes, or having to
do work to separate the local changes out before committing.

  Option ii) I could start a new branch for my own version of the
code, develop on the main branch, and propagate the changes across.
This means I don't get to develop with my local changes (which is
both a positive and a negative).  It also means I have to keep
propagating.

  Option iii) I could again start a new branch, develop on it, and
"pluck" changes back to the mainline.  This leads to problems when I
propagate back from the mainline in future.

What I'm after is something that makes this easy.  I can imagine a
number of different approaches, and I'm not sure which is the most
monotonic one:

  Change i) Stéphane's idea of a multiple checkout.  I make a branch
for my local changes.  I then do a multiple checkout of my branch and
the trunk.  The auto-merging means I get the best of both worlds.
Committing is interesting.  (You'd have to take the diffs against the
auto-merged branch, use OT theory to move that patch back before the
auto-merge, and then commit.  That shouldn't be too bad as you can
always complain to the user.)

  Change ii) Full DARCS style handling of changesets :P.  I just
don't send in the changeset for my local patches.

  Change iii) A "local branch" quilt-like system (like mercurial?).

  Change iv) Add an "auto-propagate" ability that propagates any new
revs on one branch onto a second one.  This gets "interesting" if
there are multiple heads about.

  Change v) I change my mind about wanting this feature :).

Be well,

Will           :-}



_______________________________________________
Monotone-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/monotone-devel