[darcs-users] Distributed conflicts?

[David Roundy]

On Sat, Nov 13, 2004 at 01:56:01PM +0100, Daan Leijen wrote:
> Playing with Darcs, I noticed a potential weakness of distributed version
> management.  I want to set up a "main" darcs repository, with several
> developer hacking away on specific features. Every once in a while they
> commit (push) their changes and everyone can update (pull) to see the
> changes other people make. This is how most CVS project work and it is
> good model parallel development.
> 
> Of course, Darcs should be better at this model as it supports merges
> much better than CVS, right? Well almost -- the problem is that when I
> push my changes to the main repository it will happily apply patches that
> conflict -- leaving the merge conflicts in the files on the main
> repository (effectively distributing my merge conflicts). With CVS this
> can never happen as CVS forces to "update" before being able to commit.
> The pull would force the developer to solve the conflicts locally.

Indeed, this is an annoying problem.  Darcs started out as a pull-only
system (which is all right, and easy to decentralize, but a bit of a pain),
in which case the conflict problems are never an issue.  But it seems that
push is very popular, which means 

> I guess that there are a few ways to solve this problem in Darcs:
> 
> 1) use "--test" where tests would fail on merge conflicts.  I don't like
> this at all, as I do not want to setup a test framework to make this
> safe.

Right.  I don't usually worry about this, because I set up a test framework
anyways for other reasons (i.e. testing).

> 2) use the cvs model: enforce that the local repo equals the main repo
> before being able to push.  This is an easy solution, but it is somewhat
> against the spirit of decentralized developmen. Furthermore, one gets
> trouble when there are too many commits (as in 100's per hour).

This is the policy we have in my office (pull before push), but that's
largely because although we have a test framework, it takes over an hour to
run, so we want to make sure everyone has at least compiled the merged
result of their changes before pushing.

This really isn't such a bad system, but yes, it's definitely not ideal.

> 3) do not push patches that result in conflicts by default (ask for
> confirmation?). I like this solution the most.  This would show the
> confilicting patches to the developer who can pull those patches and
> resolve them locally only if necessary. This allows everyone to work in
> parallel without ever having merge conflicts on the main repository. I
> think that this should be the default, with a flag that allows you to get
> the current behaviour (--force-merge)

I like this idea.  Unfortunately, doing it in push itself (which would
allow asking for confirmation) would require more communication, since one
would need to transfer the patches from the remote repository in order to
determine if there are conflicts.  In practice, this probably isn't a big
deal, but it changes how push behaves (or send).

Instead, I've gone for a different approach that approximates the same
behavior.  I've decided (but could perhaps be convinced to change my mind,
if people object) to change the default behavior of apply, which is called
by push on the server.  I added a new flag --dont-allow-conflicts, which is
now the default.  As one might guess from its name, apply will now fail if
the application of the patch would result in an unresolved conflict.  This
*should* have roughly the effect you suggested, except that we don't ask
for confirmation, and there's no option for the push to override this
default, although it can be overridden by changing the default apply
behavior on the target repo.

This change in default behavior means that people applying patches by hand
(or from their mailer), who probably prefer the current behavior, will need
to use the --mark-conflicts flag.  If enough people object to this, I could
make the push command specify --dont-allow-conflicts when it calls apply,
and leave --mark-conflicts as the default behavior for apply.
-- 
David Roundy
http://www.darcs.net