[darcs-users] How to develop on a (GHC) branch with darcs

[Ganesh Sittampalam]

On Mon, 6 Dec 2010, Simon Peyton-Jones wrote:

> I too wish there was a good solution here.  I've taken to making dated repos, thus
> 	http://darcs.haskell.org/ghc-new-co-17Nov10

> When it becomes unusable, I make a brand new repo, with a new date 
> starting from HEAD, pull all the old patches, unrecord them all, 
> rerecord a mega-patch, and commit.
>
> This is darcs's primary shortcoming.  It is well known, and the darcs 
> folk are working on it.  But I don't think they expect to have a 
> solution anytime soon. (Please correct me if I'm wrong.)

I think there are three things that can help with this problem:

1) a darcs rebase command. This will give you a nice way to manage the 
workflow already discussed, and you won't have to squish everything 
through into a mega-patch. You'll still have to periodically abandon one 
branch for another though (but I think that's also the case with git 
rebase). I also have some hope, though this is more speculative, of 
offering a clean way of tracking the relationship between the old branch 
and the new branch so that any stray patches against the old branch can be 
cleanly rebased to the new branch later on.

I'm actively working on rebase (with some gaps to refactor the darcs 
codebase to make working on it easier) and very much hope to have it in 
the next darcs release. Simon M has already tried out an experimental 
version and was quite positive about it, though there's significant work 
yet to do. If anyone else wants to try it, please do: see the thread at 
http://lists.osuosl.org/pipermail/darcs-users/2010-August/024924.html

2) multi-branch repos. We've pretty much agreed we need these; I think the 
strongest motivation is being able to keep the same build products around 
when switching branches. No concrete plans, but perhaps the release after 
next if we can manage it?

3) Better performance when there are conflicts, so you don't have to 
rebase as often/ever. For this you need a new patch format. GHC is using 
v1 patches, but darcs also now has v2 patches, which get into exponential 
merges much less often - but it's still possible, and we know of bugs in 
the merging which can hit in complex cases (v1 patches also have a few 
buggy corner cases). You also have to go through an explicit conversion 
step to switch to v2. I think we need to have another go at figuring out 
the problem once and for all (i.e. v3) but we don't know for sure how to 
do this.

Something related, but not exactly addressing the problems you 
all describe is:

4) Better UI around managing conflicts - one frequently requested thing is 
to be able to see the names of the patches that caused the conflicts. I'm 
working on this actively (it's also useful for rebase) and I also 
hope/expect to have this in the next release. Another thing that'll 
definitely be in the next release is that conflict marks will include the 
original text as well, so you can work out what changes each side of the 
conflict made. In my experience that actually makes a huge difference and 
it's very annoying we didn't do it earlier.

and, once we've got better at the basics,

5) we'd love to add new patch types that reduce the number of conflicts 
you get at all. Some ideas include "hunk move" patches that track when you 
move code from place to place, identation patches, and patches that track 
character changes to an individual line. Again, no timescale, but having 
refactored some of the core patch code recently it's now much clearer how 
we could do this.

Finally, I think the future holds more hybrid environments where different 
people use different VCSes and bridge between them. (At least, I hope so, 
it's the only hope darcs has of staying relevant in the wider world :-). 
Petr Rockai's recent darcs-fastconvert tool offers incremental darcs-git 
conversions, which I think should allow people who are happier with git to 
use that instead and only convert back to darcs to submit their patches.
[It may be that previous tools also offered this, I'm not certain.]

Cheers,

Ganesh