> Hmm.. No, the snapshot repo is basically the vendor branch -- it only
> contains changes from the vendor, I never pull into the snapshot repo
> from local mods. I do submit changes back to the vendor, and so they
> will eventually become incorporated in future snapshots.
This is the same situation that I have been in. It is guaranteed to trigger
darcs's "lock up and never finish merging" case, when changes that you have
made and recorded in darcs patches re-appear in new darcs patches -- the
patches that are generated from upstream snapshots. I call these "doppleganger
patches".
Your choices are:
1. Do not use darcs in this situation. Work is currently under way to invent
a new version of darcs which does not lock up in this case. I don't know how
that project is progressing or how long it is likely to take.
2. Understand what doppleganger patches are and institute workarounds to avoid
them.
2.a. One possible workaround is that whenever you pull a patch from upstream,
you figure out which of your patches are subsumed by this new upstream patch,
and you unpull your patches before pulling the upstream patch.
2.b. Another possible workaround is to have the darcs mirror of upstream
include your patches before generating new darcs patches to reflect upstream
changes. I mean, you're probably doing something like this:
/\
/ \ .____________. .____________.
/ \ | | | |
/ \ tailor.py | "mirror of | darcs pull | your |
/upstream\ ---> | upstream" | ---> | darcs repo |
\ SVN / or other | darcs repo | | |
\ / script or +------------+ +------------+
\ / manual "svn up; |
\ / darcs record" |
\/ |
|
^ |
| |
| |
upstream maintainer <---- e-mail unified diff to --------/
changes a few lines, upstream maintainer
tweaks the formatting,
and commits it with
"svn commit"
Now the thing to understand is that the first time a change makes the complete
circuit, starting in your darcs repo, being mailed to upstream, svn commited,
then turned into a new patch in the "mirror" repo, then being pulled back into
your darcs repo, then darcs will lock up! That is a doppleganger patch.
Here is workaround 2.b:
/\
/ \ .____________.
/ \ | |
/ \ | your |
/upstream\ ---> | darcs and |
\ SVN / "svn up" | SVN repo |
\ / +------------+
\ / |
\ / |
\/ |
|
^ |
| |
| |
upstream maintainer <---- e-mail unified diff to
changes a few lines, upstream maintainer
tweaks the formatting,
and commits it with
"svn commit"
The difference is that when you run "svn up" to get the upstream maintainer's
patches, then svn will overwrite your local state with whatever changes from
upstream. Therefore, if the upstream maintainer adopted your changes verbatim,
then there will be no changes according to "darcs whatsnew" after you run "svn
up". But if the maintainer changed a few things while adopting your
contribution, then those things that he changed will be reflected by "darcs
whatsnew".
There are various potential complications of this approach, starting with the
possibility that you want to maintain patches which you do *not* submit
upstream. I think adding a second repo explicitly for those "local" patches
helps with that.
3. Convince upstream to use darcs.
Regards,
Zooko
_______________________________________________
darcs-users mailing list
[email protected]
http://www.abridgegame.org/mailman/listinfo/darcs-users
