[darcs-users] Fwd: Darcs Problems

[Ben Franksen]

> Forwarding with kind permission from Sam

(Hi Eric, you may forward this to the OP if you like and he's not on the 
list.)

> ---------- Forwarded message ----------
> From: Samuel Elliott <sam at lenary.co.uk>
> Date: 20 February 2013 16:35
> Subject: Darcs Problems
> To: eric.kow at gmail.com
> 
> 
> Hey Eric,
> 
> I think it's both easier to raise my concerns in an email, and a bit 
fairer
> to do so initially, not only because I could be misunderstanding, but also
> because Darcs could be not so easy to understand.
> 
> I use git every day, and understand it (to quite an advanced level, I
> believe) and like it a lot. I also use both svn and hg occasionally - I
> dislike but can put up with both of them. Hg also has annoyances that I
> believe are systemic of their ideas too, but we're talking about darcs
> right now.
> 
> So, onto (my perceived) problems with darcs:
> 
> 1) No Branches etc. This is basically the main problem that I see. 
Firstly,
> what if I want to develop a feature not on the main "stream" of
> commits/patches in the repository? 
> What if I want to check out a previous
> tag or revision? Say if I want to make modifications to version 0.1 

Hi Sam

you do

	darcs get --tag='version 0.1' upstream-repo

and develop (and record your changes) on the resulting copy.

In Darcs, repo==branch.

> and
> then build from the modification from source, 

No problem, as 'darcs get' gives you a new copy of the sources.

> but the repo has had commits since then 

You just don't 'darcs pull' from upstream into your working copy, so the 
only changes in your repo (on top of version 0.1) are those you made 
yourself.

> and is now (effectively) version 0.2, how would I do that? 

As long as you do not pull the upstream changes that lead to version 0.2, 
you do not see them at all. I work like this all the time...

> The
> only way I could find to do this was to `darcs show changes --number`, 
look
> for the commit/patch with the message to tell me what it's up to, then
> `darcs obliterate --last=<n-1>` where n was the number beside the 
changeset
> I wanted.

No, this is not reliable and thus error-prone. Darcs might have re-ordered 
some of the changes, for instance if you have pulled an older patch at a 
later time.

> 2) Identifiers: While darcs evidently uses some kind of sha to identify
> commits/changesets/changes/patches, these aren't actually *shown* 
anywhere,

Use --xml-output to see the hashes.

However, I think that Darcs should have an extra switch (--output-hashes or 
some such) for the regular output format, too, because --xml is for tools, 
rather than human consumption and --output-hashes would be for cut-and-
paste'ing the hash that belongs to a specific patch I select.

A while ago I argued for a new Darcs feature where I can first select a 
patch (as with 'darcs changes -i') and then can operate on it (e.g. amend-
record, or push).

> nor can I use them. for example, `darcs show changes` is pretty much
> useless, with this in mind.

I don't know about 'darcs show changes'. If you mean 'darcs changes' I use 
it all the time: the patch description is more useful (to me) than the hash, 
though (as I said above) sometimes I'd like to see the hash, too.

> 3) General usability: Git is really nice in that it will automagically
> invoke `less` or equivalent if output is longer than a screen. This means
> my terminal fills up with lots of verbose, but entirely useless
> information, especially as the commits at the end of the output are the
> oldest (yes, I know I could use `reverse`, but I prefer them
> recentest->oldest and only one screen of output)

This is a matter of taste. Others have requested this, but I belong to those 
who do not like automatic paging. Also, Darcs has the --interactive (-i) 
switch for e.g. 'darcs changes', which is *extremely* useful: you step 
through the changes one by one, can go back, can make the out verbose, etc 
all interactive. I have this switch on for 'darcs changes' as my default.

> All in all it doesn't feel too usable. I really wouldn't be surprised if
> the underlying concepts were absolutely beautiful, but when it comes down
> to tooling, what's also important is that it's really nice to use - hence
> why git's model, though a bit of a leaky abstraction in places, is 
actually
> really nice to use.

I find Darcs extremely nice to use (but I have not used git before so I 
cannot compare). But one needs to understand the change-oriented model of 
Darcs: in Darcs, a repo is a set of changes. In git, a repo is a graph of 
versions (if I understood it correctly). In a version-graph, it makes sense 
to 'switch' between 'places' in the graph. In a set of changes this is not 
such a natural operation.

> Thanks for your time/interest. I hope I haven't been too harsh, but also
> that something gets changed due to my criticism.

I find the critique interesting. Some of the points you raise are (easy to 
fix, I think) weaknesses in the UI; other difficulties you mention are due 
to the mismatch of conceptual models between git and Darcs and therefore 
unavoidable.

Cheers
-- 
Ben Franksen
()  ascii ribbon campaign - against html e-mail 
/\  www.asciiribbon.org   - against proprietary attachments