monotone-devel
[Top][All Lists]
Advanced

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

Re: [Monotone-devel] Merge frustration


From: Nathaniel Smith
Subject: Re: [Monotone-devel] Merge frustration
Date: Wed, 21 Jun 2006 14:22:41 -0700
User-agent: Mutt/1.5.11+cvs20060403

On Wed, Jun 21, 2006 at 03:02:53PM +0200, Wim Oudshoorn wrote:
> Arghhhh, I have manual merging with monotone 0.26.
> 
> So now that is of my chest I can be more reasonable.
> What happened, I was doing a merge from two development
> lines which branched off quite a long time ago, and for
> some reason I got lots of merge conflicts.  So I duly set 
> out to merge them.  
> Unfortunately however, after merging file number 37 
> I  made a tiny mistake when exciting my merge tool 
> and boom monotone saw I did not merge and bailed out
> with:
> 
> monotone: misuse merge of 's/S/ChangeLog' : xxxx -> xxxx vs xxxx failed.
> 
> So now I lost all my merge work up to that point.  Grr.

Oof.  Sorry to hear that, and thanks for letting us know.

> Now don't get me wrong.  I really do like the concept of in database
> merging.  But this is really annoying.  It makes me really afraid
> of manual merges.   
> If version control systems are about not loosing work etc. 
> This behaviour seems wrong.  I need all me attention for the actual merge.

Right, totally agreed.  This is one of the reasons why our plan has
been to switch to workspace-merge instead of in-database-merge.

> Now my rant is over, but let me close by saying that I would like 
> somewhat different behaviour:
> 
> 1 - When a tree merge has conflicts, I would like to be able to
>     do my conflict resolution on all files at once.
>     I don't  like them being fed to me one by one in a random order

Workspace-merge gives you this automatically.

> 2 - If I make a mistake with merging, I don't want monotone to throw
>     out all the work I have done up to that point.

Workspace-merge gives you this automatically.

> 3 - I do like the fact that I can do a merge between two different
>     branches/revisions, withouth having one of them checked out at my
>     disk.

But obviously workspace-merge doesn't give you this :-).  (Well,
except if you start the merge by doing the checkout.  I could even
imagine a 'merge' command variant where you gave two revisions and a
scratch directory to use, and it did a checkout then workspace-merge
there.)

I am not sure how you envision getting (1) and (2) simultaneously with
(3), though.  If we are not using the workspace to hold merge state,
then where could we store the "work [you] have done up to that point"?
And how can we present you with "all files at once" any more cleanly
than by writing them all out to a directory tree, and letting you use
your standard tools?

Graydon says he likes database-merge too, and we shouldn't get rid of
it, so I guess it makes sense to make it better :-).  But I'm not sure
how to go about improving it?

> Thanks for reading to my complaints and back to work for me.

Thanks for posting your complaints :-).

-- Nathaniel

-- 
When the flush of a new-born sun fell first on Eden's green and gold,
Our father Adam sat under the Tree and scratched with a stick in the mould;
And the first rude sketch that the world had seen was joy to his mighty heart,
Till the Devil whispered behind the leaves, "It's pretty, but is it Art?"
  -- The Conundrum of the Workshops, Rudyard Kipling




reply via email to

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