<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
David Roundy wrote:<br>
<br>
<blockquote cite="mid20041113145543.GL440@abridgegame.org" type="cite">
<pre wrap="">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.
</pre>
</blockquote>
Does this also mean that if I push to a repository on a (shared) disk
that it will no longer push conflicting<br>
patches? If so, this seems a rather good solution because the
maintainter of the "main" repository can now<br>
decide whether to allow conflicting pushes or not. It would also mean
that by default, the main repository<br>
can not be messed up (which I consider an essential feature). <br>
<br>
Great! now we can emulate the "proven" cvs/svn model. It is even more
flexible as we are not forced<br>
to pull everything before a push (like a "cvs commit") -- just pulling
the patches that conflict is enough.<br>
<br>
Here is a potential weakness though: when the push is rejected it
should ideally report *why* it was<br>
rejected, ie. which patches on the target-repo conflicted with patches
in the push operation. This would<br>
allow the developer to only pull conflicting patches and resolve those
conflicts.<br>
<br>
<blockquote cite="mid20041113145543.GL440@abridgegame.org" type="cite">
<blockquote type="cite">
<pre wrap="">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).
</pre>
</blockquote>
<pre wrap=""><!---->
This is the policy we have in my office (pull before push), </pre>
</blockquote>
This is interesting -- it means that it surely pays off to make this an
easy operation. If you always<br>
do "darcs pull; darcs push", why not enforce pull before push, and just
do "darcs push"? Maybe<br>
it is a good idea to add a flag to "push", like "--pull" or something.
This way, I can edit the <br>
"_darcs/prefs/defaults" file to enforce this policy.<br>
<br>
Thanks again for all your excellent work on darcs,<br>
-- Daan.<br>
</body>
</html>