[darcs-users] Fwd: Darcs Problems

John Lato jwlato at gmail.com
Mon Feb 25 00:50:55 UTC 2013


>
> From: James Sleeman <darcs at gogo.co.nz>
>
> Stephen J. Turnbull wrote:
> >  > This works only if you take great care that nothing unrelated
> accidentally
> >  > depends on your "PostgreSQL patch set".
> >
> > Sure, although "dependencies" are a bigger issue in Darcs (where it
> > could pull in a slew of unrelated patches) than in "snapshot-oriented"
> > VCSes.  Ie, this is very simple to emulate in something like git,
> > where a
>
> To me, as somebody who would really REALLY like to use darcs more,
> dependencies are the biggest show stopper.
>
> A big feature of Darcs was (at least so I thought) cherry picking, but
> at least in my experience, the problem of dependencies means cherry
> picking just doesn't work - 90% of the time, I can't cherry pick the
> patch I want because darcs won't let me unless I take a load of other
> largely unnecessary or undesirable ones.
>
> I think have described this problem before, but to recap, basically
> there are times, many many many times, when I want to bring in some
> patch from some "branch repo" into some other "branch repo", only to
> find that the patch I want depends implicitly on patches I don't want,
> or simply can't accept in the other branch.  Most often, the
> "dependency" is just because of some trivial modification to a file, but
> that modification is contained in a much larger patch full of changes I
> wouldn't want.
>
> Ideally, I'd want to be able to bring the patch in WITHOUT some or all
> of the dependencies and have darcs present any problem as a conflict
> which can be resolved in the normal manner, and for darcs to remember
> that my conflict resolution patch is a substitute for the actual
> depended on patches.
>

This has been a big problem for me also.  In particular .cabal files and
import lists seem to lead to it, and it's especially aggravating when the
"dependency" is due to context around the change I want.  In the past I've
experimented with manually editing patches, but the most successful
approach appears to be using 'diff' and 'patch' to re-create the patch
manually.

Also, I'd like to mention that the presence of in-repo branching has more
than just technical benefits.  I've had developers tell me they think darcs
is unusable for any project developed by more than 1 person, because
without explicit branches there's no way to coordinate work.  Obviously
there's evidence to the contrary, but having support for named branches is
a powerful organizational tool.  Any DVCS that doesn't have them is at a
distinct disadvantage to git because that management overhead is now
off-loaded to the developer.

John L.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osuosl.org/pipermail/darcs-users/attachments/20130225/35a05c6e/attachment.html>


More information about the darcs-users mailing list