[darcs-users] Darcs for GHC [was: darcs weekly news #28]
marlowsd at gmail.com
Thu May 14 09:19:19 UTC 2009
On 13/05/2009 21:39, Jason Dagit wrote:
> On Wed, May 13, 2009 at 2:20 PM, Simon Marlow <marlowsd at gmail.com
> <mailto:marlowsd at gmail.com>> wrote:
> It's probably time we took another look at the options, that's all.
> Darcs still doesn't really support the development model we'd really
> like though (long-lived branches and lots of merging). On the other
> hand, darcs is supporting our other workflows reasonably well - for
> example pulling fixes into the stable branch is usually nice and easy.
> I'd like to learn more about this workflow. I know the book, "Producing
> Open Source Software" by Karl Fogle (an SVN developer), has commentary
> about branches. In particular, you don't usually want people to go
> off and work on one thing in a branch and never merge because when they
> finally do it will be painful. I don't think this is what your
> suggesting though. I think you're suggesting that you have the branch
> where they go off and do a lot of work, but they merge regularly to
> avoid the pain of infrequent merges. Is this what you're referring to?
Yes, exactly. We want to work on branches and merge with the HEAD
regularly. Darcs doesn't support this well because:
- conflicts are painful to resolve due to
(a) unhelpful conflict markers
(b) 'darcs changes' not telling you which patches conflict with
- nested conflicts lead to, if not exponential, at least very slow
performance. (admittedly I don't have hard evidence because I've
learned to avoid doing this now, but anecdotal evidence suggests
this is true).
In git we would either rebase regularly (if the branch wasn't shared) or
merge regularly (for a shared branch).
> Now, trying to understand why darcs doesn't meet your needs for this case.
> Is it because of conflicts that seem to grow ever larger as you merge in
> the future? If so, I think there was a feature planned to help with
> this, but I don't know where the status is at this time. The command
> was going to be called "transplant", if I recall correctly. There were
> a few different ideas about the semantics, and one such idea was to have
> it apply remote patches without their dependencies by creating a new
> patch containing their diff and applying it locally. Is that roughly
> what you want? A way to migrate specific patches without pulling in
> their dependencies and hence patches that create local conflicts? It
> would make the branches increasingly divergent in terms of patches but
> it would get them to a similar state of files and contents. I believe
> this functionality is similar to at least one use of Git rebase.
transplant is something I/we want too. Occasionally we need to pull a
patch into the stable branch, but without (some of) its dependencies,
and we'd like something sensible to happen - e.g. a conflict that you
have to resolve. I think Ian and I exchanged a couple of messages about
this on this list a while back.
More information about the darcs-users