[darcs-users] Re: More on version management...

Jan Braun janbraun at gmx.de
Wed Mar 24 02:09:43 UTC 2004

Graham Klyne wrote:
> At 10:26 22/03/04 -0500, David Roundy wrote:
> >
> >Well, it could be that darcs isn't for you.
> >[...]
> I find myself agreeing with Keith, but still looking for common 
> ground.  Let me see if I can articulate why this may be important.
> When working with documents in a collaborative environment (such as 
> standards authoring), it is often the case that reviewer comments are made 
> against some particular version of a document, and it is really helpful if 
> the document revision can be clearly identified in an environment where 
> changes may be occurring quite frequently.  CVS $Id: $ does this very well.
> This situation involves being able to identify a particular file version 
> that has been separated from its repository.
> Having briefly read about the Darcs approach, it seems to me that:
> - it would be feasible to include an "extra" change in the source file each 
> time a change is recorded.
> - but such changes would undermine one of darcs goals, by creating 
> otherwise unnecessary dependencies between patches.

If I may quote an IMHO excellent insight from the darcs documentration:

| One can also look at [revision control systems] as having two distinct uses.
| One is to provide a history of previous versions. The other is to keep track
| of changes that are made to the repository, and to allow these changes to be
| merged and moved from one repository to another. These two uses are distinct,
| and almost orthogonal, in the sense that a tool can support one of the two
| uses optimally while providing no support for the other.

and then:

| Darcs is not intended to maintain a history of versions, although it is
| possible to kludge together such a revision history [...]

...which seems to be the thing you're wanting to do here.

Thus you might be using the wrong tool. Don't get me wrong, I think darcs is
a wonderful program, but it's strengths are (IMHO) its decentralized nature[1]
and the ability to selectvely get some specific changes from a remote repo
("cherry picking"). I don't imagine either is particularly useful in the
context of standards authoring.
If you want just CVS without the flaws, try Subversion.
If you actually have a lot of code with a standards document embedded, then
we might have a problem ;-)

I hope this helps,

[1] which means: I can get some project's source and start hacking away,
creating my own branch in the process, without applying for "commit access"

More information about the darcs-users mailing list