[darcs-users] CVS-style development with darcs

[BARBOUR Timothy]

> -----Original Message-----
> From: Juliusz Chroboczek [mailto:jch at pps.jussieu.fr]
[...]
> To my great delight, it is possible to have a CVS-style work
> environment with darcs if you know what you're doing.

As a former CVS user, I am mindful that my old habits from CVS are not
necessarily good ways to work with darcs.

[...]
> For every branch, you'll need a darcs repository.  Fortunately,
> because darcs repositories live in the filesystem, you've got great
> freedom organising them.  You could use a flat layout:
[...]

In a playpen, you might prefer to put the branches outermost, so as not to
disrupt the relationship between projects (suppose you want make to recurse
into each of them from a top-level project). Perhaps ``branches within
modules'' is best for the "master" repos (there is no reason that the layout
in a playpen need match the layout in a set of "master" repos).

> Just like one never touches the files under /var/cvs except when
> something's gone wrong, I never cd to /var/repos; when I want to work
> on a project, I |darcs pull| into my home directory, and work from
> there.  When I want to commit, I make sure all my changes have been
> recorded, test that everything compiles, and then I |darcs push|.  If
> something goes wrong before I push, I can always unrecord.

Good idea. Maybe even better if /var/repos is on another host (in case of
failure).

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

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 ?

[...]
> 6. Darcs is unsafe

I don't understand this claim.

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

> Darcs, on the other hand, doesn't enforce any invariants except from
> honouring patch dependencies.  Patches flow randomly between repos,
> and it takes a lot of discipline to ensure they flow the way you want
> them to.
> 
> The new option --no-set-default has made this much better as it allows
> you to set up a default dataflow that never changes.  However, I find
> myself longing for ways to enforce dataflow by forbidding certain
> flows.  I certainly never want a patch to flow from head to stable
> without requiring a --force flag, and I would also like to make sure
> that I cannot push to stable from a clone of head.
> 
> I think the right design is not to forbid individual flows, but to
> have _darcs/level, an integer, and forbidding patches from flowing
> from a lower-level to a higher-level repo (think water); then I could

This sounds like a good idea.

> setup stable to have level -1, and all'd be fine.

This seems wrong way around. Since patches would be free to flow from higher
levels to lower ones, then all patches would end up in stable.
It seems better to order levels by increasing stability and give head level
0. This corresponds to the temporal order of development - we write the
unstable version first and stable releases come later.

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

Tim

-- sorry about the lame .sig --

IMPORTANT NOTICE: This e-mail and any attachment to it are intended only to be read or used by the named addressee. It is confidential and may contain legally privileged information. No confidentiality or privilege is waived or lost by any mistaken transmission to you. The RTA is not responsible for any unauthorised alterations to this e-mail or attachment to it. Views expressed in this message are those of the individual sender, and are not necessarily the views of the RTA. If you receive this e-mail in error, please immediately delete it from your system and notify the sender. You must not disclose, copy or use any part of this e-mail if you are not the intended recipient.