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
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
