[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: |
Thu, 14 Jun 2012 08:06:42 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.2 (windows-nt) |
Ethan Blanton <address@hidden> 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
- Re: [Monotone-devel] Updated Issue 209 - support drop/modified conflict, (continued)
- Re: [Monotone-devel] Updated Issue 209 - support drop/modified conflict, Stephen Leake, 2012/06/09
- Re: [Monotone-devel] Updated Issue 209 - support drop/modified conflict, Markus Wanner, 2012/06/11
- 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/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 <=
- 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