Re: To get some information regarding CVS
Mark D. Baushke
> > True, it is open-source, so anybody could in principle
> > analyze the source code to figure out the format.
>
> Yes indeed - and if anyone wants a concise list all they need to do is
> ask. A grep for "findnode.*other_delta" in the source will find all the
> nodes we add, at a quick look myself they are:
> - filename
> - commitid
For what it is worth, if rcs-5.8 is ever released, the same patch I
provided to debian [Bug #352527] (which was released as a part of rcs
5.7-18 in the debian etch release) provides a way for RCS to read and
understand the commitd extension used by CVS and CVSNT.
I had no problems working with Romain Francoise of debian or Paul Eggert
of the GNU project to adopt a final revision of the patch.
(They did choose not to accept my patch to WRITE new commitid entires
using RCS, but that is not really needed if you want something to be
able to parse existing ,v files for CVS and CVSNT.)
> - mergepoint1
> - bugid
> - permissions
>
> And I'm in the process of adding 'username' (for where the username is
> different to the author - don't ask why - it's a corner case that needs
> to be covered).
You might want to discuss the best way to do the encoding for such
things with the rcs-...@gnu.org and/or sub...@bugs.debian.org folks
before you lock it into your code base.
> As the Product Managger CVSTN at March Hare Software I think I can
> answer on behalf of 'the commercial supporters'.
>
> We are spending out effort on the areas that people who use the product
> are most often requesting that the effort be spent.
>
> You are the first person ever to have requsted the list of RCS tags,
Hmmm... I suspect that technically RCS calls them phrases in their
grammar. The RCS tags are also sometimes known/understood to be symbolic
names for revision numbers.
I personally think it is good to standardize on the RCS format
extensions within the RCS source base.
This is why I made the effort to ensure that the CVS extension of the
commitid RCS phrase was compatible with CVSNT (even though it was not
very necessariy well defined by the CVSNT folks effectively it is a
base62 string [0-9a-zA-Z][0-9a-zA-Z]*) and then I ported it to be
understandable as an RCS phrase extension by RCS so that the RCS
application would not silently strip the ,v file of that extension if it
was ever used on a CVS ,v file.
If there are good grammar definitions for mergepoint1, bugid,
permissions and username, then it would be great if they could be
shared.
Any extensions to values in the other phrases (like kopt) might also be
desirable.
-- Mark
Arthur Barrett
> For what it is worth, if rcs-5.8 is ever released, the same patch I
> provided to debian [Bug #352527] (which was released as a part of rcs
> 5.7-18 in the debian etch release) provides a way for RCS to read and
> understand the commitd extension used by CVS and CVSNT.
>
> I had no problems working with Romain Francoise of debian or
> Paul Eggert
> of the GNU project to adopt a final revision of the patch.
Hmm, that's a very good idea and very pro-active of you.
> > - mergepoint1
> > - bugid
> > - permissions
> >
> > And I'm in the process of adding 'username' (for where the
> username is
> > different to the author - don't ask why - it's a corner
> case that needs
> > to be covered).
>
> You might want to discuss the best way to do the encoding for such
> things with the rcs-...@gnu.org and/or sub...@bugs.debian.org folks
> before you lock it into your code base.
They've all been there in stable releases for 3+ years, but yes I'll
follow your lead.
> I personally think it is good to standardize on the RCS format
> extensions within the RCS source base.
Yes - very good idea - at the very least we should provide patches to
debian for new phrases and extensions to existing phrases, though it'll
be 4 weeks or so before I can get some clear air to do it...
> If there are good grammar definitions for mergepoint1, bugid,
> permissions and username, then it would be great if they could be
> shared.
Do you have an example of how these are usually expressed?
Regards,
Arthur
Mark D. Baushke
> > If there are good grammar definitions for mergepoint1, bugid,
> > permissions and username, then it would be great if they could be
> > shared.
>
> Do you have an example of how these are usually expressed?
Use the command 'man rcsfile'
For commitid, I used
{ commitid id; }
and the id itself used in CVS is a base62 encoded text. It would have
been more efficient to use a base64 encoded value for the id and put it
into a string like @id@, but CVSNT was already using it as a simple id,
so that is what we had to to in CVS to be interoperable.
I have appended the rcsfile man page for you after my .signature as an
example. This is based on the final patch submitted in February 2006
(the first patch I had submitted was in September 2005).
The CVS executable generates a slightly longer commitid than 16 bytes
used by CVSNT. CVS uses the current binary time concatenated with some
random bytes to get around simultaneous commits on the same cluser
happening at the time time... on a heavily loaded system it is possible
for the smaller commitid to be a duplicate. By using a timestamp plus a
source of random bits, this is much less likely for CVS. Although, I
will grant that it makes it harder to use the commitid as a label that
users type.
Details:
This is the code in src/main.c we use to genreate the global session ID
used for the commitid in RCS transactions for this session:
/* ... */
enum {RANDOM_BYTES = 8};
enum {COMMITID_RAW_SIZE = (sizeof(time_t) + RANDOM_BYTES)};
static char const alphabet[62] =
"0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ";
/* Divide BUF by D, returning the remainder. Replace BUF by the
quotient. BUF[0] is the most significant part of BUF.
D must not exceed UINT_MAX >> CHAR_BIT. */
static unsigned int
divide_by (unsigned char buf[COMMITID_RAW_SIZE], unsigned int d)
{
unsigned int carry = 0;
int i;
for (i = 0; i < COMMITID_RAW_SIZE; i++)
{
unsigned int byte = buf[i];
unsigned int dividend = (carry << CHAR_BIT) + byte;
buf[i] = dividend / d;
carry = dividend % d;
}
return carry;
}
static void
convert (char const input[COMMITID_RAW_SIZE], char *output)
{
static char const zero[COMMITID_RAW_SIZE] = { 0, };
unsigned char buf[COMMITID_RAW_SIZE];
size_t o = 0;
memcpy (buf, input, COMMITID_RAW_SIZE);
while (memcmp (buf, zero, COMMITID_RAW_SIZE) != 0)
output[o++] = alphabet[divide_by (buf, sizeof alphabet)];
if (! o)
output[o++] = '0';
output[o] = '\0';
}
/* ... */
/* Calculate the cvs global session ID */
{
char buf[COMMITID_RAW_SIZE] = { 0, };
char out[COMMITID_RAW_SIZE * 2];
ssize_t len = 0;
time_t rightnow = time (NULL);
char *startrand = buf + sizeof (time_t);
unsigned char *p = (unsigned char *) startrand;
size_t randbytes = RANDOM_BYTES;
int flags = O_RDONLY;
int fd;
#ifdef O_NOCTTY
flags |= O_NOCTTY;
#endif
if (rightnow != (time_t)-1)
while (rightnow > 0) {
*--p = rightnow % (UCHAR_MAX + 1);
rightnow /= UCHAR_MAX + 1;
}
else {
/* try to use more random data */
randbytes = COMMITID_RAW_SIZE;
startrand = buf;
}
fd = open ("/dev/urandom", flags);
if (fd >= 0) {
len = read (fd, startrand, randbytes);
close (fd);
}
if (len <= 0) {
/* no random data was available so use pid */
long int pid = (long int)getpid ();
p = (unsigned char *) (startrand + sizeof (pid));
while (pid > 0) {
*--p = pid % (UCHAR_MAX + 1);
pid /= UCHAR_MAX + 1;
}
}
convert(buf, out);
global_session_id = xstrdup (out);
}
/* ... */
The CHAR_BIT macro is presumed to be set by <limits.h> and is often 8.
The UCHAR_MAX macro is presumed to be set by <limits.h> and is often 255.
Enjoy!
-- Mark
$ man rcsfile | ul -tdumb
RCSFILE(5) RCSFILE(5)
NAME
rcsfile - format of RCS file
DESCRIPTION
An RCS file's contents are described by the grammar below.
The text is free format: space, backspace, tab, newline, vertical tab,
form feed, and carriage return (collectively, white space) have no sig-
nificance except in strings. However, white space cannot appear within
an id, num, or sym, and an RCS file must end with a newline.
Strings are enclosed by @. If a string contains a @, it must be dou-
bled; otherwise, strings can contain arbitrary binary data.
The meta syntax uses the following conventions: `|' (bar) separates
alternatives; `{' and `}' enclose optional phrases; `{' and `}*'
enclose phrases that can be repeated zero or more times; `{' and '}+'
enclose phrases that must appear at least once and can be repeated;
Terminal symbols are in boldface; nonterminal symbols are in italics.
rcstext ::= admin {delta}* desc {deltatext}*
admin ::= head {num};
{ branch {num}; }
access {id}*;
symbols {sym : num}*;
locks {id : num}*; {strict ;}
{ comment {string}; }
{ expand {string}; }
{ newphrase }*
delta ::= num
date num;
author id;
state {id};
branches {num}*;
next {num};
{ commitid id; }
{ newphrase }*
desc ::= desc string
deltatext ::= num
log string
{ newphrase }*
text string
num ::= {digit | .}+
digit ::= 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
id ::= {num} idchar {idchar | num}*
sym ::= {digit}* idchar {idchar | digit}*
idchar ::= any visible graphic character except special
special ::= $ | , | . | : | ; | @
string ::= @{any character, with @ doubled}*@
newphrase ::= id word* ;
word ::= id | num | string | :
Identifiers are case sensitive. Keywords are in lower case only. The
sets of keywords and identifiers can overlap. In most environments RCS
uses the ISO 8859/1 encoding: visible graphic characters are codes
041-176 and 240-377, and white space characters are codes 010-015 and
040.
Dates, which appear after the date keyword, are of the form
Y.mm.dd.hh.mm.ss, where Y is the year, mm the month (01-12), dd the day
(01-31), hh the hour (00-23), mm the minute (00-59), and ss the second
(00-60). Y contains just the last two digits of the year for years
from 1900 through 1999, and all the digits of years thereafter. Dates
use the Gregorian calendar; times use UTC.
The commitid is followed by an id token. This token is intended to be
unique across multiple files and is used to help group files as being a
part of the same logical commit. This token must uniquely identify the
commit operation that was applied to a set of RCS files. In particu-
lar, it must be unique among all the commitids in this file.
The newphrase productions in the grammar are reserved for future exten-
sions to the format of RCS files. No newphrase will begin with any
keyword already in use.
The delta nodes form a tree. All nodes whose numbers consist of a sin-
gle pair (e.g., 2.3, 2.1, 1.3, etc.) are on the trunk, and are linked
through the next field in order of decreasing numbers. The head field
in the admin node points to the head of that sequence (i.e., contains
the highest pair). The branch node in the admin node indicates the
default branch (or revision) for most RCS operations. If empty, the
default branch is the highest branch on the trunk.
All delta nodes whose numbers consist of 2n fields (n>=2) (e.g.,
3.1.1.1, 2.1.2.2, etc.) are linked as follows. All nodes whose first
2n-1 number fields are identical are linked through the next field in
order of increasing numbers. For each such sequence, the delta node
whose number is identical to the first 2n-2 number fields of the deltas
on that sequence is called the branchpoint. The branches field of a
node contains a list of the numbers of the first nodes of all sequences
for which it is a branchpoint. This list is ordered in increasing num-
bers.
The following diagram shows an example of an RCS file's organization.
Head
|
|
v / \
--------- / \
/ \ / \ | | / \ / \
/ \ / \ | 2.1 | / \ / \
/ \ / \ | | / \ / \
/1.2.1.3\ /1.3.1.1\ | | /1.2.2.2\ /1.2.2.1.1.1\
--------- --------- --------- --------- -------------
^ ^ | ^ ^
| | | | |
| | v | |
/ \ | --------- / \ |
/ \ | \ 1.3 / / \ |
/ \ ---------\ / / \-----------
/1.2.1.1\ \ / /1.2.2.1\
--------- \ / ---------
^ | ^
| | |
| v |
| --------- |
| \ 1.2 / |
----------------------\ /---------
\ /
\ /
|
|
v
---------
\ 1.1 /
\ /
\ /
\ /
IDENTIFICATION
Author: Walter F. Tichy, Purdue University, West Lafayette, IN, 47907.
Manual Page Revision: 5.6; Release Date: 1995/06/05.
Copyright (C) 1982, 1988, 1989 Walter F. Tichy.
Copyright (C) 1990, 1991, 1992, 1993, 1994, 1995 Paul Eggert.
SEE ALSO
rcsintro(1), ci(1), co(1), ident(1), rcs(1), rcsclean(1), rcsdiff(1),
rcsmerge(1), rlog(1)
Walter F. Tichy, RCS--A System for Version Control, Software--Practice
& Experience 15, 7 (July 1985), 637-654.
GNU 1995/06/05 RCSFILE(5)
$
Spiro Trikaliotis
I am answering to the ML only. I am sure anyone interested to follow
here will be subscribed, too.
* On Mon, Sep 15, 2008 at 08:45:42AM +1000 Arthur Barrett wrote:
> Just noticed Spiro's comment on the 22nd August in the thread "Obtaining
> the files modified/created after a failed/successfulbuild of CVS
> repository".
No problem. I just noticed your mail here. ;)
> > Indeed, cvs2svn/cvs2git does not support CVSNT (though it often mostly
> > works if you use the --use-cvs option). And one main reason
> > is that the
> > CVSNT format is not well documented. I've also heard rumors that the
> > format has changed over time, but I don't know if that is true.
>
> The CVSNT format is the RCS format, it is documented in the RCS man
> page.
The format: Yes, but not the "tags" as you call them.
> 1a.
> As I have written here and elsewhere in the past - the primary reason
> why 3rd party tools fail to read CVSNT repositories is that they fail to
> ignore tags that they do not understand.
[...]
As I never tried to parse CVSNT files myself, I cannot comment on this.
Anyway, thanks for the explanations of what might be the
differences/extentions and/or difficulties of parsing the CVSNT format.
> > If anybody wants to add CVSNT
> > support to
> > cvs2svn/cvs2git, I would be happy to help them.
>
> I think the main reason why noone is contributing this effort is that
> people are more interested in moving from SVN and CVS to CVSNT since
> CVSNT provides the features of those other systems plus many more.
I am sorry to say this, but from my experience, this is not the case.
I am quite sure that SVN is taking much "market share" from CVS and
CVSNT. If this is reasonable or not, I do not want to comment it.
> I am regularly approached by project managers and QA managers who want
> to move their organisations to CVSNT (primarily for the failsafe audit,
> but often also for the merge tracking and other features) and who are
> facing 'developer revolts' because the developers will not use anything
> except a SVN client.
<...and removed shameless plug...>
Again, this is not my experience, not my personal one, and not the
experience of many people I am speaking with.
> These questions of Michael's, as with any other CVSNT question should be
> asked on the CVSNT newsgroup.
Well, Michael just answered to someone who has a question here, and he
told him why it is not supported. That's all.
In the same way as you are answering CVSNT specific questions here, it
is Michael's right to answer other questions here, too.
> If someone has a question and do not ask it of the people who have the
> capacity to answer it then it is unfair to claim that there is no answer
> to the question.
The problem here is mainly that most of the documentation is not
obvious. If Michael (or someone else) goes out and asks on the CVSNT
newsgroup in order to support CVSNT repositories - he can be almost be
sure that this information will not be completely true in the near
future. The CVS people are much more "conservative" when it comes to
introducing incompatible changes. This has its advantages - and, of
course, some disadvantages, too.
> I'm not at all sure what Spiro meant by "reasons *not* to use CVSNT" -
> unless he meant that a reason not to use CVSNT is that we do not provide
> answers magically to questions that are never asked of us
No, that's not true. And I think, we have discussed so much in the past
that you should know that this is not the case.
> and that we
> listen to our users and solve the problems that they are asking to be
> solved.
Of course, it is a good idea to listen to the customers. I would never
question this!
> To me and all our customers and open source users they are
> great reasons to use CVSNT.
Well, again, from my experience, most people who are using CVSNT are
using it because they believe it would be the only way to use CVS on
Windows machines, or because WinCVS (or TortoiseCVS) uses it
"internally". Almost all of them would be perfectly o.k. with "plain" CVS.
> Of course there are many people (like Spiro I believe) who do not want
> the 'additional features' of CVSNT and prefer the 'simplicity' of CVS -
> and for people who understand this then it is a perfectly sensible
> choice to make.
Well, I do not need most of the additional features of CVSNT. Anyway,
there is one feature that is very important for me: I want to be able to
convert my repositories to other formats if it is necessary. With plain
CVS, I can be almost sure that this will be possible for some time. For
CVSNT, this is not possible even now in many cases.
If it is the fault of CVSNT or of the writers of the 3rd party tools: I
do not know. In fact, I do not care. I just want to be able to do it.
That's my main reason I am not using CVSNT - and I am pretty sure you
already know this.
Regards,
Spiro.
--
Spiro R. Trikaliotis http://opencbm.sf.net/
http://www.trikaliotis.net/ http://www.viceteam.org/
Michael Haggerty
> 1.
>> Indeed, cvs2svn/cvs2git does not support CVSNT (though it often mostly
>> works if you use the --use-cvs option). And one main reason
>> is that the
>> CVSNT format is not well documented. I've also heard rumors that the
>> format has changed over time, but I don't know if that is true.
>
> The CVSNT format is the RCS format, it is documented in the RCS man
> page.
>
> As I have written here and elsewhere in the past - the primary reason
> why 3rd party tools fail to read CVSNT repositories is that they fail to
> tool creating RCS files is evolving every day, and so there will always
> be tags that are not understood by 3rd party programs - therefore it is
> critical that they ignore tags that they do not understand.
Well, the syntax is (almost) the same as that of RCS, which is nice for
parsing the CVSNT repository files. But the schema is different.
Unfortunately, we need to know both :-)
cvs2svn ignores tags that it does not understand, which indeed gets us
most of the way there. Nevertheless, we get many inquiries on the
cvs2svn users' mailing list that turn out to be people trying to migrate
away from CVSNT repositories and having problems because of other
differences.
> The second difference is in valid options to standard tags (like kopt).
> In this case it's all documented in the cvsnt manual (but again - the
> best way to code is to ignore things that are not understood):
> http://cvsnt.org/manual/
This is typically the real problem. CVSNT apparently allows new values
for the filewise "expand" keyword, and also adds the revisionwise "kopt"
keyword. If the meanings of these values is documented somewhere, a
pointer would be much appreciated. The CVSNT manual link that you sent
me has a little bit of user-level information about the "binary"
options, but I couldn't find information at the level of detail that I
would need.
At first we certainly wouldn't try to read the file content out of the
CVSNT repository--for that we would use "cvs co -p" as we do now in
--use-cvs mode. But we need to understand the metadata.
By the way, we use the same rcsparse infrastructure as used by ViewVC,
so the CVSNT project itself would directly benefit the ability of third
party tools to understand your repository format.
> Thirdly there are "unclear" parts of the RCS spec (or at least unclear
> to me). So on windows it is not unusual to have a "space" in the users
> name. So RCS files written by CVSNT may write a domain qualified
> username with spaces to the author field which many 'unix only'
> interpretations of the RCS spec do not handle. Ditto for filenames with
> spaces.
That's one difference that we already know about and handle.
> 1b.
> The CVSNT project just like the cvs2svn project relies on contributors
> to write the documentation, as you write:
>
>> True, it is open-source, so anybody could in principle
>> analyze the source code to figure out the format.
>
> Yes indeed - and if anyone wants a concise list all they need to do is
> ask. A grep for "findnode.*other_delta" in the source will find all the
> nodes we add, at a quick look myself they are:
> - filename
> - commitid
> - mergepoint1
> - bugid
> - permissions
Thanks for the pointers.
filename -- I don't know what this is, so I can't guess whether it would
be interesting for cvs2svn.
commitid -- I assume this is the same thing that recent versions of CVS
use; we don't use that information yet but could easily do so.
mergepoint1 -- would probably be interesting if we every want to
recreate merge information in the target repository.
bugid -- presumably allows a connection to a bug database; at most we
might consider migrating the information to a tag in the output
repository for the use of other user tools.
permissions -- from the name of it, this is probably not interesting
right now, since we don't try to migrate permission information to SVN.
> And I'm in the process of adding 'username' (for where the username is
> different to the author - don't ask why - it's a corner case that needs
> to be covered).
I'm afraid I'm going to ask why anyway :-) Is it like the difference
between "author" and "committer" in git? cvs2svn can commit to git,
too, so this metadata might also be useful.
>> If anybody wants to add CVSNT support to
>> cvs2svn/cvs2git, I would be happy to help them.
>
> I think the main reason why noone is contributing this effort is that
> people are more interested in moving from SVN and CVS to CVSNT since
> [...blah...blah...]
Yeah. Right. :-)
Michael
Arthur Barrett
> for the filewise "expand" keyword, and also adds the
> revisionwise "kopt"
> keyword. If the meanings of these values is documented somewhere, a
> pointer would be much appreciated. The CVSNT manual link
http://www.cvsnt.org/manual/html/Substitution-modes.html
The keywords themselves can be used defined - so this list is arbitrary.
http://www.cvsnt.org/manual/html/Keyword-substitution.html
And
http://www.cvsnt.org/manual/html/User-Defined-Keywords.html
> that you sent
> me has a little bit of user-level information about the "binary"
> options, but I couldn't find information at the level of detail that I
> would need.
If you need more detail than what is shown in the above links you'll
have to ask for it explicitly on the CVSNT newsgroup - but all the
information I can think of that you'd need is there.
> By the way, we use the same rcsparse infrastructure as used by ViewVC,
> so the CVSNT project itself would directly benefit the
> ability of third
> party tools to understand your repository format.
I know that many users of CVSNT do use ViewVC and that Bo Berglund spent
quite a lot of time on both projects - I'm surprised it's not already
there - if it's not then the patches Bo made probably were never
accepted, and I'd not be interested in duplicating his effort.
> filename -- I don't know what this is, so I can't guess
> whether it would
> be interesting for cvs2svn.
The filename - err, name of the file? Since CVSNT supports rename the
name of the RCS file is not necessarily the name of each revision of the
file.
> bugid -- presumably allows a connection to a bug database; at most we
> might consider migrating the information to a tag in the output
> repository for the use of other user tools.
That wouldn't work which is why we have bug id's - a single bug id can
appear on many revisions. Then when you need to merge a bug the server
can collect all of the revisions that are relavent - bugs are rarely
fixed in a single commit. As far as I know SVN has not equivalent.
> permissions -- from the name of it, this is probably not interesting
> right now, since we don't try to migrate permission
> information to SVN.
Again no SVN equivalent.
> > And I'm in the process of adding 'username' (for where the
> username is
> > different to the author - don't ask why - it's a corner
> case that needs
> > to be covered).
>
> I'm afraid I'm going to ask why anyway :-) Is it like the difference
> between "author" and "committer" in git? cvs2svn can commit to git,
> too, so this metadata might also be useful.
I guess so - do you have a link that explains the difference in Git?
> >> If anybody wants to add CVSNT support to
> >> cvs2svn/cvs2git, I would be happy to help them.
> >
> > I think the main reason why noone is contributing this
> effort is that
> > people are more interested in moving from SVN and CVS to CVSNT since
> > [...blah...blah...]
>
> Yeah. Right. :-)
>
Well no - this is a serious issue for anyone whose jobs are about CM or
that support FOSS software use in the enterprise. I'll break it into
roughly 3 categories:
1) unnecessary duplication of effort (in open source projects)
2) wasted money by organisations who use the software leading to
disenfranchisement with the OSS model
3) a lack of education on CM and the 'real' benefits/purpose of it
Point (1) is a minor philosophical point that has already been
documented and acknowledged the world over that due to egos in the FOSS
comunities that there is far too much duplication of effort. Whilst
having choice is a good thing - I've not seen a single feature in SVN
that is not delivered better and years in advance in CVS or CVSNT. The
couple of things that SVN does marginally better (eg: fast tagging -
'logical' human user interface to express branches) could have been done
in a fraction of the time and effort on the CVS or CVSNT source code.
Now the CVS project has made it clear over the years that they don't
want 'feature bloat' so it makes sense that there is at least one
alternative.
Point (2) has been best documented by a University in France and
summarised in a great article on the valuation of IT assets published in
The Financial Times UK Edition 36,501 on Monday October 1 2007. In
short the cost of migrating from CVS or CVSNT to SVN is huge, and as I
already indicated above is not based on any benefit the organisation
will see. This is bad for FOSS since it will be seen as a contributing
factor - when an organisation stipulates ClearCase they get universal
subscription and it never changes over decades - much better for
business.
Point (3) comes back to what I originally wrote - CM has a purpose in an
organisation and no Software CM /VC tool should be employed until it
demonstrates a benefit towards that purpose. Generally I find the
business driver for CM in an organisation to be either: a need to manage
(customer initiated) changes (patch / bug etc), developer productivity,
security/control/legislation. In none of these areas does SVN
contribute anything that CVS does not supply (there is no
user-defined-change-sets unless you also have the collabnet tools, there
is no clear productivity gains, there is not security (no failsafe
audit, no file/branch level access control unless you also purchase the
collabnet tools).
With the EVSCM project we've create a Version Control/CM API (library
thingy) that can in theory be used to build many different CM systems,
and an open source implementation with audit, user-defined-change-sets
and secutiry (ie: identical to the current CVSNT but built on the
generic API) and we are also building a commercial implementation that
provides a process/workflow, a nice web interface and support for Web
Folders, CVS/CVSNT, SVN and TeamSystem clients. But there is no way
that I'd personally encourage anyone to migrate unless they have
documented the costs and investigated the benefits.
Having choice is a good thing - and the svn migrate utility a good one -
and I am happy to supply whatever information is needed to make it work
with CVSNT - because I see openness as important. There are also bigger
issues at stake that I think should not be dismissed. Would you
consider putting some warning on the user interface for cvs2svn? If I
had my way it's be "you are about to perform an action that is
completely unnecessary and likely to cost you a lot of time and money -
are you sure you want to migrate to a system that has no feature that
CVS doesn't already have? We recommend a cost/benefit analysis and a
clear definition of the business (bottom line) benefit to your
organisation before you continue. Walk away now while you still can.",
but I'm sure you could come up with something a little more moderate ;)
Regards,
Arthur Barrett