[darcs-users] Distributed conflicts?

Daan Leijen 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 
conflicts.

>>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,
-- Daan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osuosl.org/pipermail/darcs-users/attachments/20041114/81251a56/attachment.htm 


More information about the darcs-users mailing list