[darcs-users] Distributed conflicts?
daan at cs.uu.nl
Sun Nov 14 15:38:43 UTC 2004
David Roundy wrote:
>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.
Does this also mean that if I push to a repository on a (shared) disk
that it will no longer push conflicting
patches? If so, this seems a rather good solution because the
maintainter of the "main" repository can now
decide whether to allow conflicting pushes or not. It would also mean
that by default, the main repository
can not be messed up (which I consider an essential feature).
Great! now we can emulate the "proven" cvs/svn model. It is even more
flexible as we are not forced
to pull everything before a push (like a "cvs commit") -- just pulling
the patches that conflict is enough.
Here is a potential weakness though: when the push is rejected it should
ideally report *why* it was
rejected, ie. which patches on the target-repo conflicted with patches
in the push operation. This would
allow the developer to only pull conflicting patches and resolve those
>>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),
This is interesting -- it means that it surely pays off to make this an
easy operation. If you always
do "darcs pull; darcs push", why not enforce pull before push, and just
do "darcs push"? Maybe
it is a good idea to add a flag to "push", like "--pull" or something.
This way, I can edit the
"_darcs/prefs/defaults" file to enforce this policy.
Thanks again for all your excellent work on darcs,
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the darcs-users