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

Jason Dagit dagit at codersbase.com
Thu Sep 3 18:00:26 UTC 2009

On Wed, Aug 26, 2009 at 9:24 AM, Simon Michael<simon at joyful.com> wrote:
> Yes. A good article, but I can't make sense of the three paragraphs where he
> talks about darcs.

It took me a while to read the whole thing, but I've finally finished.
 What I like about this article is that it tells us what are the great
features of other vcs.  Which I see as an opportunity for inspiration
and refinement.

I like this paragraph:
For an example of novel publication, Mercurial supports ad hoc
publication of repositories over a LAN using its built-in Web server,
and it supports discovery of repositories using the Bonjour protocol.
This is a potent combination for rapid development settings such as a
software project's sprint: just open your laptop, share your
repositories, and your Wi-Fi neighbors can find and pull your changes
immediately, with no server infrastructure required.

That's a pretty cool feature.  Darcs should borrow this cool idea!
Ad-hoc networks to share patches.

This paragraph was interesting to me as well:
Both Mercurial and Git decouple fetching remote changes from merging
them with local changes. If Bob fetches Alice's revisions, he can
still commit his changes without needing to merge with hers first.
When he merges afterward, he will still have a permanent record of his
committed changes. If the merge runs into trouble, he will be able to
recover his earlier work.

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.  Or if files you are working with are
renamed it could be confusing too.  In darcs, I think the best
practice is to record your local changes first.  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

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

There could be other annotations explaining why it's a good idea to
record the changes first also:
Unrecorded local changes detected.  Pulling patches will merge the
changes over your working copy.  If you record your local changes
first it will be easier to separate them from the new updates later,
especially if there are conflicts.  How to proceed? [i,r,q,?]


More information about the darcs-users mailing list