Re: Updated Issue 209 - support drop/modified conflict

Ethan Blanton <[email protected]> writes:

> We have this:
>
> <toplevel>/
>     libpurple/
>     pidgin/
>     finch/
>         libgnt/
>
> There are other directories in the branch (and you are correct, I said
> 'repository' where I meant 'branch'; I reguarly use three different
> DVCSes these days, and the terms start to get fast and loose ;-)), but
> they are unimportant here.
>
> Suppose that we want to be able to release libpurple and libgnt
> separately for those who desire, as well as a monolithic repository.

You are implying that "release" means "make a mtn branch available for
pull", as opposed to "put a .tar.gz on a webpage"; obviously, there
would be no problem with the latter.

> We're then going to have:
>
> <toplevel>
>     libpurple/
>
> <toplevel>
>     libgnt/
>
> <toplevel>
>     libpurple/
>     pidgin/
>     finch/
>         libgnt/
>
> There are two ways to arrive at this; only one is viable given that we
> *already have* the example above, but I'll cover them both.
>
> 1) Break libpurple/ and finch/libgnt/ out into their own branches, and
>    perform the requisite drops and moves to structure them for
>    standalone release.  We then want to be able to merge changes to
>    shared files back and forth between the standalone branch and the
>    monolithic branch.  We don't want to have to babysit monotone when
>    pidgin/gtkmain.c changes and we propagate to the libpurple branch.
>    I think this is precisely what this thread is about; if I
>    misunderstand, please correct.  We also don't want dies to
>    propagate from libpurple/ to the monolithic branch; again, we want
>    to say "no" to that option precisely once, and never see it again
>    (unless more files are dropped in the future).  This requires
>    complete suspension of die-die-die in both directions, which I
>    think is what this thread is *working* toward, if it hasn't reached
>    it already.

Ok. That's an interesting use case.

I think the proposed 'conflict resolution' attribute could handle this;
please think about that.

I think a better approach is to provide support in mtn for
'meta-projects', that make handling multiple branches as easy as
handling single branches, but that's a different discussion.

> 2) Create libpurple, libgnt, and finch/pidgin branches, and suture
>    libpurple and libgnt into the finch/pidgin branch.  

This is a different meaning of "suture" than we have been using; this is
a "branch suture"; we have been talking about "file suture".

>> Would any of the mechanisms proposed in this thread help?
>> 
>> Is some other CM system better?

CVS would help, because you can checkout any sub-tree of the repository.
But you don't want to go back to CVS just for that :(.

> This is the prime question; I don't know.  In my empirical experience,
> drop + modify becomes painful at some point everywhere I've been.

Can you elaborate on how, exactly, it becomes painful?

> However, I've never had the opportunity to try a massive drop+modify
> restructuring such as described above, so I don't know if things would
> eventually smooth themselves out. 

Right, it is hard to tell without good examples.

> I think git probably would. 

Can you say how?

>> An alternate is to live with the 'ignoring upstream changes due to local
>> delete' warning in 1.0.
>> 
>> Why is that not ok?
>
> Two reasons; 1) noisy merges are bad.  

I agree with that! that's part of the reason I want to promote
drop/modified to a conflict.

> You really want to tell the user once, let them say "yeah, I really
> mean it", and shut up about it. 

Right.

> 2) (and this is a little bit outside of this thread, but I
> think closely related) die-die-die prevents cross-propagation of
> either this decision or changes to the undead files in one branch.

I'm not clear what you mean here.

> Now, take all of this Pidgin noise with a grain of salt; we're
> actually mid-process of converting our repositories to hg, so while I
> think our experience is valuable going forward, our direct needs are
> about to be removed from the monotone picture.

Unfortunate, especially since it sounds like there might have been a
chance to stay with mtn if we had developed a solution to this problem.

-- 
-- Stephe