On 13/05/2009 21:39, Jason Dagit wrote:
On Wed, May 13, 2009 at 2:20 PM, Simon Marlow <[email protected]
<mailto:[email protected]>> 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[1]. 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
each other
- 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.
Cheers,
Simon
_______________________________________________
darcs-users mailing list
[email protected]
http://lists.osuosl.org/mailman/listinfo/darcs-users
