[darcs-users] Re: More on version management...
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.
| 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
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,
 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