[darcs-users] Darcs equivalent of force-pushing and branching

[Stephen J. Turnbull]

James Cook writes:

 > I've used git with multiple working directories, and it is nice.
 > 
 > darcs uses hard links to save space, so having multiple clones should
 > be relatively cheap.

Right, but that's talking about physical resources.  I think those are
quite plentiful for most developers nowadays, unless you're working on
something where you need to integrate video or large databases -- but
those aren't in your repo (at least, they wouldn't be in mine! :-)

I'm talking about the mental resources (7 +/- 2 items in short-term
memory, that stuff).  Some of my projects (well, all of them nowadays
:-( ) I frequently go some weeks without active work on them.  I don't
forget implementation details in the period, but I often forget which
names go with which details.  So it's helpful to me to have the
upstream (nowadays I call it "pristine"), local (my own current
project of interest), and review (where I check out other workers'
branches) workspaces, separated by purpose rather than current
content.  That workflow and that memory issue may be unique to me.

 > > All of this is obviously quite possible with Darcs.  The problem is
 > > getting the "accounting" right when separating the management of
 > > *sets* of patches from the management of *histories*.  IIRC, in Darcs
 > > the history is in the patches, which means a bit of tedious surgery on
 > > data structures needs to be done.
 > 
 > I'm not sure what you mean by "histories" as distinct from "sets of
 > patches". Shouldn't a branch just be a set of patches?

Apparently not, see Ben's response for accurate details.

It turns out that Darcs patches are more abstract than I thought.  I'm
sorry for introducing confusion here. :-þ  In my defense, I'll say I've
been working with "atomic commits" and some sort of "patch theory"
starting with Tom Lord's Arch (the collection of bash scripts, not tla
the C program!)  It's hard to keep all the design details straight,
especially if you don't read some of the implementation languages
(specifically Haskell) like a native.

Steve