[darcs-users] Making Sense of Revision-control Systems by Bryan O'Sullivan

Trent W. Buck twb at cybersource.com.au
Fri Sep 4 01:22:43 UTC 2009


Jason Dagit <dagit at codersbase.com> writes:

> It sounds to me like, darcs partially decouples this.  It merges them
> in and keeps them separate, but it does so over top of your working
> copy.  So if you have something you're working on it could get
> conflict markers over top of it.

In the past I have done

    darcs pull --allow-conflicts --all --union foo bar baz

to fetch all patches from some other places into a local copy.  I ignore
the working tree in that local copy (cf. --no-working-tree), and simply
use it as a cache from which to pull patches into my "real" repositories
when offline.

> In darcs, I think the best practice is to record your local changes
> first.

In general, I agree, but I would be very strongly opposed to Darcs
*enforcing* (as opposed to recommending) this workflow.  "hg fetch" does
that to me, and its amazingly annoying.

> Perhaps we should consider refining darcs's UI in this case.  For
> example, what if darcs could warn you when you have unrecorded changes
> locally before allowing you to pull in new changes?  Here is an
> example to illustrate my point using a mocked up session:
>
> darcs pull foo
> Unrecorded local changes detected.  How to proceed? [i,r,q,?]
> ?
> i: ignore the unrecorded changes and proceed with the pull.
> r: record the changes first and then proceed with the pull (Note: You
> will be able to unrecord or amend-record your changes later.)
> q: quit
> ?: help

For me, this would be disruptive and annoying.  I vastly prefer to
simply have --dont-allow-conflicts in my .darcs/defaults (and it should
be the default, IMO) -- if I'm working on one part of the repo, Darcs
should not pester me if I try to pull in someone else's work on another
part of the repo -- not until they conflict, anyway.

For at least one repo (my dotfiles), I effectively NEVER have a state
where all changes to the working tree are recorded.

I would not object to a non-interactive "warning: unrecorded changes".

> With a corresponding --dont-warn-unrecorded that can be set in the
> user's defaults for scripts and people who think this feature is
> obnoxious.

Fine, except for bloating the number of options :-)



More information about the darcs-users mailing list