I think I find having a new option (--skip-conflicts) to be much
cleaner (and clearer) as I give an exact indication of what I want: I
accept to take just the non-conflicting patches. At the same time the
--dont-allow-conflicts option has already established a well defined
meaning among users which does not suggest a partial operation.
Changing its meaning will not only make its behavior surprising to
older users, but the non-atomicity of the new behavior can make it
troublesome especially for push, since the user didn't indicate that
it's OK to have a non-atomic pull/push and he may only find it
afterwards that he brought the code in the repository in a non-
functional state.
Sometimes there are reverse dependencies between patches at a logical
level. For example I make a change with patch number 1 that is a
preparatory change for a change that I plan to make later with patch
number 2. I do not push patch 1 until I also have patch 2 done. Patch
2 has a direct dependency on patch 1, that can even be expressed as a
darcs dependency between patches. However at a logical level there is
a reverse dependency for patch 1 on patch 2, in the sense that without
patch 2, the code is incomplete and non-functional. It's only the
developer that can decide if a partial push is fine or not. An option
like --dont-allow-conflicts cannot make such a decision automatically.
This will also have another side effect that affects the ease of use.
Not knowing in advance if I will have a conflict and not being able
anymore to rely on --dont-allow-conflicts to skip everything if there
is a conflict, I will have to run push twice. One time with --dry-run
and only if everything is OK a second time without it.
On 29 Sep 2009, at 23:57, Ganesh Sittampalam wrote:
(1) Repurpose --dont-allow-conflicts for both pull and apply
- slightly complicated exit code behaviour
- changes existing functionality
- push isn't atomic any more: you might get some but not all changes
applied
(2) Add a new option --skip-conflicts for both pull and apply
- requires a new option and extra code to support
(3) Repurpose --dont-allow-conflicts just for pull
- changes existing functionality
- apply and pull become inconsistent
(4) = (1) + Add --dont-allow-conflicts to push and make it the
default
- some more work (but I could probably do it soon)
- slightly complicated exit code behaviour
- changes existing functionality
- push might get slower/more network intensive by default
(5) = (1) + Add --dont-allow-conflicts to push and don't make it the
default
- some more work (but I could probably do it soon)
- slightly complicated exit code behaviour
- changes existing functionality
- push is no longer atomic by default
(6) Enhance --match to detect conflicts, as per previous discussion
+ general interface
+ solves another feature request too
- significantly more work (I probably won't have time in the near
future)
- also requires a behaviour change to the 'touch' matcher for
consistency
- not obvious that --match should be based on properties *after* the
merge
--
Dan
_______________________________________________
darcs-users mailing list
[email protected]
http://lists.osuosl.org/mailman/listinfo/darcs-users
