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

[Ethan Blanton]

Stephen Leake spake unto us the following wisdom:
> Markus Wanner <address@hidden> writes:
> > However, another perfectly valid use case is wanting to permanently
> > delete a file in a child branch, which might continue to get modified in
> > the parent branch. You'd not want that to conflict every time you
> > propagate, do you? (The warning is annoying enough, already).
> 
> I don't see this as a valid use case; can you elaborate?

This is a bogus statement.  It is absolutely valid.  I have run across
precisely this use case multiple times using monotone, and been unable
to implement it due to die-die-die merge.  "I don't see this as a use
case I want to support" is a reasonable statement, instead.

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.

In the absence of either robust repository suturing or
die-only-in-child for cross merges (neither of which does monotone
support), managing this in monotone is very limiting.  We have settled
on "OK, you just have to check out all the crap you don't want".  This
is understandably not ideal, and many people would prefer us to
provide three or four different repositories.  Of course, if we did
that, the vast majority of our users (who just use Pidgin) would be
annoyed that they have to fetch and build at least two packages.

I'm not going to make the claim that this particular use case is
*critical*, but it is absolutely *valid*.

Ethan

signature.asc
Description: Digital signature