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

[Stephen Leake]

Ethan Blanton <address@hidden> writes:

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

No, it is a statement about my lack of experience, and lack of
imagination (or time to spend imagining).

And a request for more information about the experiences others have
had. Thank you for sharing yours.

> It is absolutely valid. 

I agree, now that a couple of use cases have been explained.

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

I think we _should_ support this use case; I'm surprised there has not
been more effort in this regard.

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

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

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

Would any of the mechanisms proposed in this thread help?

Is some other CM system better?

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

I would like you to explain this use case in more detail, so I can be
sure I understand what new mechanism might be helpful.

> This is understandably not ideal, and many people would prefer us to
> provide three or four different repositories. 

If you are using 'repository' (= database) in the mtn sense, think you
mean 'three or four branches', not 'three or four repositories'. But
maybe you are using 'repository' in some other sense; I'll take this to
mean 'mtn branches'.

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

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.

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.

-- 
-- Stephe