[darcs-users] Fwd: Darcs Problems

Stephen J. Turnbull stephen at xemacs.org
Fri Feb 22 13:19:06 UTC 2013


Ben Franksen writes:

 > Sure. But (as I tried to explain) while this is a natural opration in a 
 > history-based system (move the view to another point in time), if you see a 
 > repo as a *set* of changes, this is not well-defined: you must specify which 
 > changes should be in the "branch".

Which is a feature missing from Darcs, not from the "repo as set of
changes" model.  That is, a single repo ("universe of patches") could
support multiple branches ("sets of patches").  Eg, as lists of
patches.

 > >  > No problem, as 'darcs get' gives you a new copy of the sources.
 > > 
 > > This is slow 
 > 
 > On the same file system? Not slow IME.

It's damn slow if you are working on something the size of XEmacs and
you have a `create-branch-auto-if-needed-and-check-in-on-auto'
function on your save-file-hook!  This allowed the following workflow
to be fast and convenient:

Start work in branch "feature".
Find typo relevant to all branches.
Save (and automatically check in on branch "auto").
Switch to branch "typos", and refresh file in XEmacs buffer.  (Emcs
  reminds you if you forget.)
Fix typo.
Check in on "typos".
Switch back to "auto".
Finish this stage of work on the feature.
Save (and automatically check in on "auto" branch).
Merge "auto" to "feature".

At some later time, rebase the "typos" branch to mainline.  *Note that
you will get no conflicts when merging mainline to "feature", because
the typos commits aren't on "feature" or "auto".*

I'm not currently using this workflow because it's too heavyweight for
my very linear "class notes" repos in my day job, and it's no longer
usable in XEmacs (where I'm often juggling 5-10 branches when
development is very active) because hg doesn't support it very well,
while Mercurial queues (which are patch-based) work quite well.

Also, note that the above is just an example, demonstrating the
principle that in git, the answer to "I have a problem" is always
"branch it!"  (Just like the proverb that "In computing, there's no
problem that can't be solved by another layer of indirection"!)

 > Besides any slowness is only when you create the branch for the
 > first time.

No, it's also slow when you rebuild because it's now a build for the
first time.  Or you can cd again and pull the patch, build, and then
obliterate (or something like that).

I very quickly lose track of where I am and what changes are
appropriate to files in that directory when I do that, though.  This
is a generic problem for me in "branch is repo" VCSes (it bugs me in
hg and bzr branches, too).

 > Obviously we have different experiences here.

Right; I'm not complaining about Darcs, I'm trying to explain my
perspective, because there's a fairly good chance much of it is
similar to the OP's.  These things are often hard to express.

I don't know if much can be done to make the Darcs experience more
git-like, and maybe it shouldn't be, anyway.  OTOH, I think it quite
likely that heavy Darcs users can probably advise him how to amend his
workflow to be more comfortable -- if they can understand what itch he
needs to scratch.

 > >  > 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.
 > > 
 > > I don't see why not.  Tom Lord (the great Grampaw of modern open
 > > source VC) used to argue that your VCS is the right place to do many
 > > kinds of configuration.  For example, you don't want PostgreSQL
 > > bindings in this instance of your app?  Unapply the "PostgreSQL patch
 > > set" and rebuild.  
 > 
 > This works only if you take great care that nothing unrelated accidentally 
 > depends on your "PostgreSQL patch set".

Sure, although "dependencies" are a bigger issue in Darcs (where it
could pull in a slew of unrelated patches) than in "snapshot-oriented"
VCSes.  Ie, this is very simple to emulate in something like git,
where a tag corresponds exactly to a source tree (plus some
development history, but the SCM application can ignore that).

There the problem is that there's no basic datatype that corresponds
to a "feature".  It's difficult to use the VCS to examine the
modularity of your feature.  OTOH, in Darcs, you dig up the "set of
patches" that corresponds to your feature, check if they commute with
the rest of the repo[1], and if they do, bingo! you've got good
modularity of the feature.  At least in theory! :-)  But AFAICS, Darcs
doesn't actually support this query (yet? :-).

 > > This doesn't happen to correspond to Darcs very well (since it
 > > doesn't really have a notion of feature = patch set), but that's
 > > a limitation of Darcs, not of repo-as-a-set-of-changes.  (That
 > > line of development didn't work out very well, but it's not clear
 > > to me that it wasn't more for lack of effort on Tom's part than
 > > any defect in the idea itself.)
 > 
 > Could you explain this with a bit more detail? Which line of development do 
 > you mean?

The "line of development" was Tom's various attempts at merging the
concepts of VCS (for keeping development history) and SCM (system
configuration management for distribution).  As you point out above,
the big problem with doing SCM this way (and it was true of the Arch
family, which also basically functioned in terms of "set of patches",
though the "Arch theory of patches" was "let the developer figure it
out!" :-) is that you have to find a way to manage the various
dependencies so that a "configuration" only has the features (and code
to support them) you want, without causing merge conflicts or pulling
in unwanted dependent patches.


Footnotes: 
[1]  More precisely, with the rest of the set of patches since the
"base version" that this feature presumes.




More information about the darcs-users mailing list