[darcs-devel] splitting and merging patches

[Ganesh Sittampalam]

Hi David,

On 15/03/2013 22:24, David Leuschner wrote:
> And that's the problem and the reason why I'm looking for a different
> split.  For use rebase leads to an unacceptable solution because W
> change to W' (and fortunately with duplicates there's a way to replace
> X with some X' without changing W.  Here's the real world use case:
[...]
> This may happen more often to us than to others because of our special
> repository structure that only works if dependencies are right.  We've
> also got some very strict additional policies regarding patch naming
> and "no conflicts". All "official" branches may never contain
> conflicting patches.  We've used Darcs 1 a long time and are very
> happy how good everything works if conflicts only happen in private
> user repositories and conflicts are solved by amend-recording and
> sequencing patches.
> 
> So please keep the "duplicates"-feature - we might not be using Darcs
> anymore if this feature wouldn't work so good for us.

Thanks for the explanation!

As discussed elsewhere in the thread, I think history rewriting patches
would address the W->W' issue in the long term.

In the meantime, we should avoid breaking the existing use you're making
of duplicates.

The "duplicate patches don't conflict" thing is fundamental to darcs-2
patches anyway, and although we might remove it in darcs-3 patches if
and when they come along, we wouldn't remove darcs-2 patches for a long
time after that.

The fact that you can abuse duplicates to substitute patches is a bit
more problematic - I think you mentioned that you've encountered darcs
erroring out as a result, and I'm fairly sure that in general one can
use tags+patch substitution to thoroughly confuse darcs - but it's not
something that comes up often in practice so I think we can live with
leaving things as they are for now.

As far as split and merge go, I think if you want to maintain the patch
identity above, then you should write a separate tool to do it. While we
wouldn't want to cause a regression for you, making it easier to
use/explicitly advertising the duplicates misfeature would be a step too
far.

In theory a separate tool can reuse much of the rebase infrastructure -
in particular with the current implementation, you would only really
need a version of 'rebase unsuspend' that doesn't change patch identity,
as it's preserved up to that point. But you'd need to be pretty careful,
because rebase allows a lot more than split/merge, and you could get
into even more trouble by doing anything else. So it would probably be
more sensible to wrap the whole process up into something higher-level.

I hope that sounds reasonable - if you go down this route, I'm of course
happy to advise Sebastian on the implementation as needed.

Cheers,

Ganesh