[darcs-users] Initial impressions of darcs

[Scott L. Burson]

Hi,

Well, I haven't actually used darcs for anything yet, but I have skimmed the 
manual a second time.  (Sorry for my stupid question the other day; the 
manual does make the correct procedure quite clear.  That's what I get for 
getting excited about darcs while I'm madly trying to meet a project deadline 
:-)

Certainly my first impression was "Aha!  Someone has finally done this the 
right way!"  Meaning, (a) focussed on deltas (patches) rather than whole 
configurations, and (b) looked at the problem mathematically (David's 
protestations about hating math notwithstanding :-).

As I look at the manual, though, I do perceive what seem to me to be gaps in 
darcs' functionality.  (Please, correct any misimpressions I may reveal in 
what follows.)  While most SCM systems focus on configurations and treat 
deltas weakly, darcs has a very strong treatment of deltas --- but doesn't 
seem so good with configurations.

Let me suggest a very simple theory of configurations: a configuration is 
either null or is the result of applying a set of patches to another 
configuration.

Specifically, I gather that a darcs repository can contain only one 
configuration, which is the result of applying all the patches in the 
repository to the null configuration.  Changing the configuration of the 
repository requires adding or deleting patches.

I would suggest a more flexible model in which a repository may contain any 
number of configurations.  Configurations may be tagged with names, as 
currently, or specified as a tagged configuration plus a set of patches.  The 
repository would always be in a particular configuration, but could easily 
and efficiently be changed to a different one.  Communication of patches 
between repositories would also transmit tag definitions (maybe this happens 
already).

Such a design raises this question: given that I've pulled some patches into 
my repository, how do I specify (or even know) which configuration I want it 
to enter, i.e., which subset of those patches I actually want to use?   
Making this easy seems to require one more concept, which I will call a 
"patchline" (the best name I can think of at the moment).  A patchline is a 
named set of patches published by a specific single repository R.  The owner 
of R may add new patches to the patchline until it is closed.  A given client 
repository may be subscribed to any number of patchlines (possibly from 
different repositories), which means that by default, when patches are pulled 
from R, they will include all the patches in the patchlines R publishes; it 
also means that the repository will by default enter the configuration 
containing all patches in all patchlines to which it subscribes.  The client 
repository's owner could select a different configuration; this would 
temporarily suspend any subscriptions to patchlines containing patches 
omitted in that configuration.

These are all just ideas, and far from a fleshed-out, concrete proposal, but 
it does seem to me that something along these lines would make darcs more 
powerful.

-- Scott