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

[Jamie Webb]

On Fri, Nov 11, 2005 at 11:37:28AM +0900, Stephen J. Turnbull wrote:
> "The" Enemy?  Conflicts are a PITA and spurious ones slow down work
> unnecessarily.  It's worthwhile to invest in systems to reduce them,
> but it is preferable to have the computer do the work rather than have
> humans waiting on each other.  Developers should talk to each other,
> but about design and defects and fixing.  Scutwork and waiting is for
> the machines.

We don't end up waiting around, we just try to organise who does what
at any given time roughly along code boundaries. If I think I'm at
risk of stomping on someone else's changes, I have a few options:

a) Continue anyway if it looks like any conflicts will be minor.
b) Ask the other person to make that change.
c) If they aren't working on it right now, ask for a patch of their
changes to date.
d) Work on something else until they are done.

And of course there are a lot of factors that affect my choice, but in
general one or other seems reasonable. I see it as just good manners
to stop and think for a second before 'dropping bombs', as you put it,
on other people's work in progress.

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

I meant in the context of an SCM. If we're talking about what slows
down a project most overall, that would be the customer...

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

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

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

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

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

...
> It's not impossible to do with distributed projects, but it's harder.
...
> And to the extent that the project takes a lot of small contributions
> from volunteers, it becomes nearly impossible, because they don't
> punch the time clock at all.

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

Either way, I suppose the codebase is a big consideration. Code that's
factored in the right way will be much friendlier to an SCM than code
that requires bouncing across half the files in the project for every
change that's made. And open-source ought in theory to have an
advantage there, since there's less of an 'anything to meet the
deadline' mentality. And ugly code might attract fewer developers to
create conflicts...

-- Jamie Webb