[darcs-users] Fwd: Darcs Problems

[Ben Franksen]

Hi Stephen

You wrote:
> Ben Franksen writes:
> 
>  > In Darcs, repo==branch.
> 
> The OP undoubtedly wants colocated branches which are fast and very
> lightweight.  

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".

> OTOH, many of the things I use fast branching for in git
> projects simply don't come up under Darcs' model of the world -- I'd
> use cherrypicking instead.
> 
>  > No problem, as 'darcs get' gives you a new copy of the sources.
> 
> This is slow 

On the same file system? Not slow IME. Besides any slowness is only when you 
create the branch for the first time. Afterwards you do 'cd' instead of 'vcs 
switch branch' and that should be fast enough ;-)

> and requires changing directories to work, 

Yes.

> not to mention
> a "make world" rather than a "make one .o and relink".  

This is a bit risky, but I do this in Darcs, too, sometimes. I.e. I have two 
parallel repos (branches), say project/std and project/without-postgres. I 
can pull a patch from one branch to the other, then build there. Only 
difference is that I have both build results (one per branch dir).

> Darcs has
> gotten somewhat faster since I used it with XEmacs, but making a new
> branch was annoyingly slow back then (and I only had a couple hundred
> patches when the project switched to Mercurial), 

See above.

> and any merge could
> take forever.  I can't say that I wouldn't have found an efficient and
> comfortable workflow (my experiment with XEmacs in Darcs only lasted
> about 4 months), but there's no question that I found it quite
> constraining (aka "unnatural") compared to git or hg.

Obviously we have different experiences here.

>  > 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.
> 
> 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". I could be wrong but as I see it, 
this is independent of VCS.

> 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?

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