Re: Updated Issue 209 - support drop/modified conflict

Ethan Blanton <[email protected]>
Newsgroups gmane.comp.version-control.monotone.devel
Message-ID <20120613021924.GC6686@colt>
Stephen Leake spake unto us the following wisdom:
> Markus Wanner <[email protected]> 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

_______________________________________________
Monotone-devel mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/monotone-devel
signature.asc (application/pgp-signature, 482 B)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEVAwUBT9f4rP8fixZ3H8crAQgHiwf8DM/BkRjiTQbKjxlOUjd70tAUy6B/GkSk
JehSYPLssAYELBNFh8pgoDOvrAfqGZkJdH7G59UhrZvh5J5J5DROqlgqw8YtYUFT
uIEVlMT8WIGx3A+OrydeGXwbHD+G2ZVaDIFtyy3yciSkKxlEFVbNkUFB1udKx/ZK
P8Gotv+xVejYwKGERBSwP+R/TKfr1szhNiUE8ee0YZmtz6cfmGxLy5V5t323vhvC
7wtdMkjOnIHTnz6z49ULzgP/037xNEZYBxCOtjumCO2JHB9KK15+us9ITABEGNhY
KxroEQxh3CvOdc9kF/CpTOhvCTjfrmNJA8Lb3CEauXuI4Z3x2lRDEQ==
=Py3s
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.