Re: [Monotone-devel] Updated Issue 209 - support drop/modified conflict

[Hendrik Boom]

On Fri, Jun 08, 2012 at 02:24:48PM +0200, Markus Wanner wrote:
>...
>...
>
> > My prefered solution for that case would be to split the project into
> > five (or more) projects; win32 support, unix support, common
> > project; release project 1 contains common, unix, and win32; release
> > project two contains common and unix.
> 
> Now assume the parent project is not under your control. Your preferred
> solution is to split the project into different branches and you want to
> do that in your fork. In the win32 branch, you certainly don't ever want
> the unix files. And vice versa. You delete them. And you are cento
> percento sicuro you don't ever want to see them again.
> 
> The parent project continues as it did before. You want to propagate
> their changes to your fork. Every modification from the parent project
> will currently invoke the warning about the modification not being
> visible in your sub-project, because of the files you deleted.

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.

>...
>...
> 
> In principle, I like the attribute approach better. However, there's the
> technical difficulty of being unable to store attributes on deleted files.
> 
> (Also note that during the liveliness tracking and merging discussion,
> Nathaniel brought up the example of OpenEmbedded, who happens to create
> and delete lots of files in their process. So that if monotone never
> really deletes a file, but keeps it in its manifest with an "invisible"
> attribute or some such, the overhead from deleted files would soon
> surpass the amount of data for live files).

What'd the overhead for deleted files now?  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.

>...
>...
> 
> It just occurs to me that this resembles the case of copying files. For
> a user, it's just copying a file. However, afterward, there are two
> options on how to merge modifications to "copied" files, which I've seen
> referred to as "symmetrical" and "asymmetrical" copy: either the merge
> only adjusts the original file (asym), leaving the copy as is. Or it
> could duplicate that modification as well and apply the modification to
> both files as part of the merge. There exist valid use cases for both
> variants. My point for this discussion is: I think that's another case
> where the user has a better chance of understanding the effects of his
> decision when asked at the time of the merge (instead of at commit time).

It sounds like the same kind of problem.  Merging should just work if 
both sides have the copying in their ancestry.  Otherwise, there are 
decisions to be made, which might even involve line-by-line casuistry.

> 
> 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?

>...
>...
>
> Comments?

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?"  

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.

-- hendrik