[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] Updated Issue 209 - support drop/modified conflict
From: |
Stephen Leake |
Subject: |
Re: [Monotone-devel] Updated Issue 209 - support drop/modified conflict |
Date: |
Sat, 09 Jun 2012 10:58:33 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.2 (windows-nt) |
Hendrik Boom <address@hidden> writes:
> Here we're discussing seriously the case I wondered about ages ago,
> where you want to split a project into several projects, but later
> decide to bring them back together. You have the problen of decidint=g
> which files to merge, and which files have more-or-less become different
> files, both of which need to be kept.
But you only do that once; we're discussing a case where the conflict
can reoccur on many occasions as the project moves forward (the upstream
vs local case).
> What'd the overhead for deleted files now?
none.
> With the problematical merges we're discuccing, we have to have some
> mechanism in place to discover that a deletion has been performed in
> the distant past on one of the nerging branches. Presumably that
> implementation mechanism would suffice -- the file doesn't need to be
> mentioned in the manifest for us to implement this model.
This is addressed in the sutures branch. The required information is
stored in the mark/merge cache, not in the revs themselves (the revs do
store the immediate parents of a suture). So it's still 'overhead', but
I'm not sure how much that matters.
>> Complicating things, I don't think it's a file specific decision. Maybe
>> there exist use cases where you want to ignore modifications from the
>> parent project, but at least want to see a warning, or even better a
>> real conflict, if somebody else from your project tried to modify the
>> file "before" seeing your deletion.
>
> It can even be a line-by-line decision. You deleted this line on branch
> A, but modified it on branch B. It's a conflict. What do you want? Is
> this really any different from the case with files?
Yikes. Let's not go there ...
> This whole discussion relates to the user-interface for merges.
>
> When I'm faced with a merge, I'd sometimes like to be able to say, "Hey,
> wait a minute, this takes serious thought. Could you please put all
> this stuff in my workspace without doing the merge, so I can pull out my
> whole development toolkit ans work out what has to be done?"
You can do that now; check out both heads in independent workspaces,
and use your dev kit to compare changes and merge into one final
workspace, then commit that.
The mtn conflict process is a compromise on that; it makes all the
required information (rev ids, file ids) available, so a decent
front-end tool can help in the process, with only one workspace checked
out. See Emacs DVC.
> I'd sometimes even like the possibility of doing the merge a bit at a
> time, each time reporting progress to monotone until it's finally
> done.
If that's because there are multiple revisions on each side, then zipper
merge (merging each pair of revisions, rather than just the heads) is a
good approach.
If it's because there are lots of files, the current 'mtn conflicts'
commands give you that.
--
-- Stephe
- Re: [Monotone-devel] Updated Issue 209 - support drop/modified conflict, richhguard-monotone, 2012/06/07
- Re: [Monotone-devel] Updated Issue 209 - support drop/modified conflict, Ethan Blanton, 2012/06/12
- Re: [Monotone-devel] Updated Issue 209 - support drop/modified conflict, Stephen Leake, 2012/06/13
- Re: [Monotone-devel] Updated Issue 209 - support drop/modified conflict, Ethan Blanton, 2012/06/13
- Re: [Monotone-devel] Updated Issue 209 - support drop/modified conflict, Stephen Leake, 2012/06/14
- Re: [Monotone-devel] Updated Issue 209 - support drop/modified conflict, Hendrik Boom, 2012/06/14
- Re: [Monotone-devel] Updated Issue 209 - support drop/modified conflict, Stephen Leake, 2012/06/15
Re: [Monotone-devel] Updated Issue 209 - support drop/modified conflict, richhguard-monotone, 2012/06/08