[darcs-users] removing conflicts in a repository

David Roundy droundy at abridgegame.org
Sun Apr 4 14:10:39 UTC 2004


On Sat, Apr 03, 2004 at 11:23:04PM -0800, Tupshin Harper wrote:
> What is the appropriate method of dealing with patches that create 
> conflicts in a repository, particularly if the repository is designed to 
> be the "canonical source", and really should never had patches removed 
> from it. Is unpull/unrecord the only appropriate action?
> 
> Right now, we have an archive (http://core.ibex.org) that claims to be 
> consistent, and an rsynched version of it also claims to be consistent, 
> but a version pulled via darcs get (via http or local file url, and 
> partial or complete) all result in an archive that is inconsistent.
> 
> I believe that conflicts are the source of the problem, but it is hard 
> to be certain. Having an easy way to track down which patches cause 
> conflicts would also be a very good thing.

This repository (http://core.ibex.org) is indeed consistent, in the sense
that it has no errors in it.  A conflict is distinct from an
inconsistency.

I think I see what the problem is by running darcs get on the above repo,
then unpulling a few patches and re-pulling them.  Then I get the
following:

$ darcs pull -a
Pulling from http://core.ibex.org...
So far so good... finished merging.
We have conflicts in the following files:
./Makefile.upstream
Finished pulling.
$ darcs whatsnew 
{
hunk ./Makefile.upstream 20
-url_bcel-5.1           := http://apache.webmeta.com/jakarta/bcel/binaries/bcel-5.1.tar.gz
+v v v v v v v
+url_bcel-5.1           := http://mirrors.mix5.com/apache/jakarta/bcel/binaries/bcel-5.1.tar.gz
hunk ./Makefile.upstream 23
+*************
+url_bcel-5.1           := http://www.apache.org/dist/jakarta/bcel/binaries/bcel-5.1.tar.gz
+^ ^ ^ ^ ^ ^ ^
}

This shows that the conflict was between a patch that changed url_bcel-5.1
from to http://apache.webmeta.com/jakarta/... to
http://mirrors.mix5.com/apache/jakarta/... and one that changed it to
http://www.apache.org/dist/jakarta/.

The two patches that did these were "fix for(key in obj)" and "upstream
apache.webmeta site went away...using more canonical source for bcel".

At to how to fix it so there won't be a problem, you can do this by adding
another patch that modifies this line.  The only catch is that it can't
modify it to be the original value, since that is what darcs does "by
default" when it sees the conflict, so it won't know the conflict has been
resolved.  You could get around this either by adding a bit of "harmless"
whitespace, or by creating two patches.  Both are ugly solutions, and
eventually I'd like to come up with a cleaner way to resolve a conflict
between two changes by simply ignoring both of them.
-- 
David Roundy
http://www.abridgegame.org




More information about the darcs-users mailing list