Re: [Monotone-devel] some (negative) feedback -- useful reading

[Ethan Blanton]

Nathaniel Smith spake unto us the following wisdom:
> I don't know what "disapprove, true merges are hard" means.  I don't
> know what "phil does not have send a key" means.  (Who is Phil? :-))

I don't know about the first two, but I can guess about "true merges
are hard", because it's an issue I take seriously with monotone for my
own usage ... monotone has what I would call "revision merges", where
the existing data in the database is merged, but this is insufficient.
What I would call a "logical merge" is what I believe they are calling
a "true merge", which is a merge in which not only is the revision
info straightened out, but any additional logical changes to make the
codebase sane are taken care of.  That is to say, integrating two
changesets is not as easy as applying both patches and committing
simply because there are no conflicts -- there can be higher-order
"conflicts" which no revision control system can be expected to find.

I am under the impression that this is an understood problem, and that
a solution (namely, merge in working area) will be forthcoming after
other things (like rosters, sqlite 3 changes) are straightened out.
As I am an academic user with mostly private projects, the current
lack of polish in this area is acceptable to me -- but if I were a
larger project with many developers (e.g., OpenEmbedded), I might view
it as a showstopper.

Ethan

-- 
The laws that forbid the carrying of arms are laws [that have no remedy
for evils].  They disarm only those who are neither inclined nor
determined to commit crimes.
                -- Cesare Beccaria, "On Crimes and Punishments", 1764

pgpHerfu_stg_.pgp
Description: PGP signature