Before: Shall I record this change? (1/8) [ynWesfvplxdaqjk], or ? for help:

After: Shall I record this change? (1/8) [ynW...], or ? for more options:

Darcs 2.5 and up should be a little bit friendlier. Thanks for the UI bug!

You wrote

“Long-time darcs users have no doubt trained themselves to not notice this stuff.”

but on the contrary every one of the five behaviours you objected to are behaviours that I explicitly like and that I consciously prefer over the alternative behaviours of other revision control tools. I think most long-time darcs users feel similarly about them.

For the record, that’s:

1. “darcs record” instead of “darcs commit”

This terminological distinction is important because running darcs record is *not* committing you to anything and does not expose your team-mates to the consequences of your work. This is a fundamental difference in workflow which is generally prefered by darcs users. A few times I’ve observed people misunderstanding darcs workflow by thinking that “darcs record” is like “svn commit”.

2. “–all” is not the default

This default setting is valuable because the common case for long-time darcs users is to choose only a subset of edits to batch together into one darcs patch. This is a change in workflow which is much beloved by almost all long-time darcs users — it means you can opportunistically make an unrelated change as you are working on a different change and then sort them into logical patches later.

3. many features available by keystroke at the interactive prompt

I really like this behaviour. When I started out with darcs I used only four or five of the options, but over time I’ve learned more and more of them and I enjoy the convenience and power they offer.

4. cbreak mode

I prefer this. Darcs on Windows does not have the ability to do this, so I use both cbreak and non-cbreak darcs every day, and I know which one I prefer.

5. “patch name” is an arbitrary length, arbitrary content, human readable string instead of a more restricted format

I prefer this, but perhaps it would be nice if it were called something other than “name”, in order to allay the irritation that many including you have experienced.

Regards,

Zooko,

long-time darcs user

Darcs does have configurable defaults. They are documented in the manual:

http://www.darcs.net/manual/node5.html#SECTION00510010000000000000

If you want “darcs record –all” to be the default behavior for you, it can be.

Addenda:

1. darcs does have programmable defaults:
http://programming.reddit.com/info/yq1t/comments/cyve8?context=5&style=nested#cyve8

2. Maintenance vs prototype programming has some mapping with [stevey's notions of hardware and software](http://steve-yegge.blogspot.com/2007/01/pinocchio-problem.html) and with [the packer-mapper dichotomy](http://www.reciprocality.org/Reciprocality/r0).

Interactive commit is good where the emphasis is on maintenance and bug tracking. It’s hell if you’re rapid-prototyping, though. My big problem was that I could never remember to commit at the right times when I was hacking something up, trying out options. And spending my neurons on remembering to commit made the Zone less accessible. My solution – to train myself to think aloud about my code: http://www.cs.utexas.edu/~akkartik/feed.cgi?codelog.html

“Have you ever written something but only after adding some scaffolding or debugging code? Do you really want that code in there?”

Again, it depends. If it’s just a private repo I care more about maintaining a record of the sequence of events rather than patch hygiene.

The amend-record trick is a good one, though.

I have objections to the underpinnings of darcs’s patch theory, too, but those are for a different posting.

Lets take interactive commits for instance. You complain about having to say yes to every commit… but why don’t you ask the following questions:

1) Have you ever written something but only after adding some scaffolding or debugging code? Do you really want that code in there?

2) Has one bug made you aware of another? Fixing two things in one tangled patch seems wrong. You should fix them but use record to track them appropriately.

3) Have you ever made some important changes and then forgot about a few of the unimportant whitespace changes that you made? Do you wish you could just avoid committing all that?

4) Is it really that easy to read through larger diff output than a case by case basis? Shouldn’t you give a careful check to things as you read over things in interactive mode?

5) Have you ever thought “oops” I forgot that change was in there… abort commit, edit, and start commit again? Why not just avoid the change and handle that other part after (with revert, ammend-record, etc…)

6) Do you really commit often enough? I usually have extremely small changes that can easily be tracked and managed. This means darcs rec is very quick and there are very few y’s.

7) Did you know you can incrementally build patches with ammend-record? This is a great tool to sort things out. It would be much less valuable if you had to write the changes in separate branches. I commonly create a parallel debug patch for some code so I can move it in and out quickly when and where it is needed for a certain bug.

Has a friend/co-worker/other person ever asked you for a quick change, yet you were in the middle of a big change and didn’t want to make a branch _just_ to do a one liner or typo fix? Quick interactive commits avoid changes that might be in the same file.

9) Conflicts are hard to avoid sometimes but when you can see the hunks separately it can really help to see what the dependent areas are. When I am cooperatively coding with a team it has been nice to be able to proactively be aware of what my footprint is so I know when to warn about certain lines or areas that a someone else might be working on. (I commonly play a patch ping-pong with someone else… this really helps a lot).

10)alias commit=darcs rec -a is simple enough if none of the above suite you.

… yes … I admit that interactive commits is one of the main reasons I use darcs. There are many more things that could be brought up as well.

Really… I think it might take some serious experimenting on your part before I would let a blog entry like this pass as a good beginner review.

Ok. Now for the positive side. At least you are one of the few who has the guts to not only try something new but you also are willing to gripe about things you don’t quite like yet. Give it some time and it might come to you… otherwise there are some other great SCMs out there like mercurial or different git setups (just don’t get stuck with the cvs/svn mind-set).