[darcs-users] darcs patch: Resolve issue1588: make --dont-allow-conflicts filter ...

[Dan Pascu]

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