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

[Ethan Blanton]

Stephen Leake spake unto us the following wisdom:
> > As a concrete example, the Pidgin project, for historical reasons and
> > as a position that I will admit not everyone agrees with, has a single
> > repository containing 1) libpurple, a library implementing the guts of
> > an instant messaging client plus protocol implementations; 2) libgnt,
> > an ncurses-based widget library; 3) Pidgin, a Gtk+ instant messaging
> > client, and 4) finch, a gnt instant messaging client.  Both libpurple
> > and libgnt are complete, standalone products that can be used, and
> > *are* used, by third-party software.  Libpurple is used extensively in
> > this manner by other high-profile projects such as Adium, an IM client
> > for OS X.
> 
> Sounds messy, but I don't see why that requires deleting files in a
> local branch.

Not necessarily local, but deleting files and then allowing two-way
merges between the deleted files and their non-deleted merges without
spurious notifications or propagating the deletes in the undesired
direction.  The key is that you want to remember the user's decision
with respect to delete & merge, and not talk about it again; more
below.

> > In the absence of either robust repository suturing 
> 
> suturing does not help in the case of simply deleting files. Which means
> I don't understand your use case.

It's the converse to the delete solution to this particular use case;
more below.

> > or die-only-in-child for cross merges (neither of which does monotone
> > support), managing this in monotone is very limiting. 
> 
> What do you mean 'limiting'? What is mtn preventing you from doing? I
> don't see what the actual problem is (feel free to blame my lack of
> imagination).

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

2) Create libpurple, libgnt, and finch/pidgin branches, and suture
   libpurple and libgnt into the finch/pidgin branch.  This direction
   doesn't require nearly as much dead file state management, but it
   requires sutures, which monotone also doesn't support.  In our case
   it's not reasonable, because the monolithic branch already exists,
   but for people without historical baggage it's a reasonable
   approach and greatly reduces the history size of the standalone
   branches.

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

This is the prime question; I don't know.  In my empirical experience,
drop + modify becomes painful at some point everywhere I've been.
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.  I think git probably would.  I
don't know about hg or bzr, and nothing else really matters for this
particular discussion.

> > We have settled on "OK, you just have to check out all the crap you
> > don't want". 
> 
> You are implying you would prefer to delete all the files you are not
> using.
> 
> 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.  You really want to tell the
user once, let them say "yeah, I really mean it", and shut up about
it.  Users _have to read_ merge noise.  There could be critically
important stuff in there.  In this case, we're talking about dozens to
hundreds of files.  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.

> Yes. I maintain several packages (mtn branches, all in the same mtn
> database) for my main system at work. I've written Lua functions to
> make it easier to manage them together, but it is not as simple as a
> single branch.

At least one project I work on (that uses hg) uses external build
scripts to manage such a case.  It's understandably not ideal.
Monotone is not alone in poor handling for this case.  Both git and
subversion have *some* sort of handling for this case, but I've not
been entirely pleased with their outcomes in the past.

> The solution to that is a true multi-package distribution/build system,
> such as Debian dpkg. Which is a lot of work, unless you are already
> using Debian.

Maybe.

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.

Ethan

signature.asc
Description: Digital signature