[darcs-users] Resolving conflicts in a push only repo

[Stephen J. Turnbull]

>>>>> "Jamie" == Jamie Webb <j at jmawebb.cjb.net> writes:

    Jamie> We don't end up waiting around, we just try to organise who
    Jamie> does what at any given time roughly along code
    Jamie> boundaries.

Sure.  It works for you, it works for a lot of projects.  I don't
think it will be universal, or even close, that's all.

    >> If conflicts get elevated to the level of "the" enemy,
    >> something's wrong.

    Jamie> I meant in the context of an SCM.

Well, me too.  For the SCM's developers, conflicts are The Enemy.  But
for the users, conflicts should be something that the SCM handles and
they don't have to think about the mechanics, only the cases where
there are genuine conflicts.

    >> I doubt you have a Disruptive Genius type working on your
    >> project, then.  A "general idea" of what a guy is working on,
    >> when he can produce 100K lines of diffs in three months at an
    >> average level of quality higher than the existing code base, is
    >> simply not good enough.

    Jamie> Hmm... I think it's possible to be a genius and still be
    Jamie> polite.

It's not a one-way issue.  When I say "disruptive", I don't mean
"bull in a china shop", I mean "urban renewal".

    >> I don't ask a revision control system to deal with that
    >> automagically.  I do want it to deal with conflicts more
    >> gracefully than either darcs or CVS do, because I expect there
    >> will be many.

    Jamie> But how can a tool do a better job than CVS? Certainly
    Jamie> Darcs could avoid even more conflicts, e.g. with the
    Jamie> suggested whitespace patch type, or by considering language
    Jamie> syntax. And David says his Conflictor code will help with
    Jamie> the exponential time problem. But having a found a genuine
    Jamie> conflict, what is there to do but mark it for manual
    Jamie> correction?

    Jamie> Possibly a good interactive tool could help, but there
    Jamie> doesn't seem much to be done but find the conflict markers
    Jamie> and hand over to an editor.

Well ...

1.  There should be a "sync-tree" command like in Arch that says "code
that is identical in these trees should admit the same patches
regardless of history differences."
2.  It should be possible to say that certain kinds of patches _never_
participate in conflicts (eg, prepending a log to a ChangeLog file).
3.  A pair of multihunk patches that conflict on single hunk should be
automatically split into patches containing the hunks that don't
conflict and patches that do.  The original patches should be replaced
(again, automatically) by empty patches that depend on the split
patches.
4.  A scimmer utility that heuristically skims scum from the project.
ChangeLogs are unnecessary, for example.  Use darcs changes, instead.
In C code, David's canonical "identical text is a conflict" example is
bad style; don't use #define MAX_ENUMERATOR, use enum tagvalues {
FIRST_ENUMERATOR, ..., LAST_ENUMERATOR, MAX_ENUMERATOR }.

I'm sure I could think of more, but the others that come immediately
to mind are pretty clearly in the editor domain.

    Jamie> Well, small contributions are less likely to conflict, and
    Jamie> it seems to me that large contributions tend to be
    Jamie> pre-announced anyway, because people don't want to
    Jamie> duplicate work, or write code that won't be accepted.

My experience has been that preannouncement doesn't alleviate
conflicts.


-- 
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.