[darcs-users] CVS-style development with darcs

[David Roundy]

On Fri, Jul 02, 2004 at 12:36:45PM +1000, BARBOUR Timothy wrote:
> > From: Juliusz Chroboczek [mailto:jch at pps.jussieu.fr]
> > 4. Darcs doesn't like large trees
> > 
> > CVS loves large trees.  You can checkout just part of a large tree,
> > and a CVS working directory doesn't cost much.  I've spent years
> > working on a 500MB tree using a machine with just 32MB of memory and
> > 4GB of disk space (the repository was remote, obviously).
> > 
> > There's no way I could do that with darcs; the tree would need to be
> > split into multiple repos.  I guess that's not a problem, just
> > something you need to be aware of when setting up your repos, although
> > I wouldn't want to be the one moving the XFree86 tree into darcs.
> 
> How bad is the behaviour of darcs with large trees? Where is the
> threshold? I don't like the idea of splitting up a project just because
> of darcs performance constraints.

I've tested darcs on a repo with a 187M tree (the linux kernel).  It's
pretty slow, and takes a lot of RAM, but it vaguely useable.  On the other
hand, trying to get change history out of it would probably be impossible,
unless you have a much faster computer than I do.  That, of course, is
because darcs is completely unoptimized with respect to queries for
information.

> AFAIK, darcs has no way to split a darcs project, or join separate darcs
> projects. I am not sure whether such ability is possible or desirable, but
> in its absence, one has to think carefully about how to allocate code to
> projects, and hope that it will not need to change. Does anyone know some
> principles for doing this ?

My thoughts on the subject are that one should divide your project
logically.  The linux kernel obviously can't easily be divided, and
shouldn't be.  But if you've got several independent but related projects
in the same CVS repository, I would say that they definitely should each go
in their own darcs repository.

It sort of looks like I've said nothing at all in answer to your question,
and yet written quite a bit...

> > The reason why people (me included) love CVS is that CVS is safe.
> > There is no way you can ever lose data that has been committed without
> > doing manual surgery on /var/cvs/.  This gives you a peace of mind
> > that is difficult to understand if you haven't been exposed to CVS.
> 
> CVS never throws away ones work, even if it has not been committed (unless
> one insists on doing a release -d).
> Is there any circumstance where darcs throws away work ?

If you add a file to darcs and then run darcs revert, the file will be
deleted.  Of course, you could unrevert to get it back, but if you revert
again before realizing what happened, you could lose valuable data.

> > An apology of switch
> > 
> > As I've mentioned before, darcs makes me uneasy because many commands
> > are potentially unsafe.  Hence, I'm looking for ways to extend it with
> > operations that have guaranteed safety properties.
> > 
> > In order to go back in time with darcs, you need to manually unpull a
> > bunch of patches.  Not only is that tedious, but it is a dangerous
> > operation: unless you are very careful, you run the risk of unpulling
> > a patch that you haven't pulled yet.
> > 
> > The solution is |switch|.  It roughly corresponds to |cvs update -r|
> > and |svn switch|.  In darcs, it would look like
> > 
> >   darcs switch [--match match] [--context context] [ [repo1] repo2]
> > 
> > which unpulls all the patches present in repo1 but not repo2, then
> > pulls all the patches present in repo2 but not repo1.  Both match and
> > context apply to repo2.
> 
> switch sounds like a useful command, however I am not sure whether it is
> really necessary. There were times when I switched my CVS playpen between
> branches. However I noticed that it was typically better to use different
> playpens for different branches, and I would often create a temporary
> playpen for dealing with a particular version. Surely it is always possible
> to rename away a playpen, get a different version in its place, then rename
> back when done (or is this too expensive with darcs ?). This seems to avoid
> the dangers you mentioned.

Indeed, it looks like a nice command, but I'd always do the same thing with
two repos, one for each version, and just record the patch with name "foo",
and pull it into the other repo to test.
-- 
David Roundy
http://www.abridgegame.org