RE: To get some information regarding CVS

[Arthur Barrett]

Spiro/Michael,

Just noticed Spiro's comment on the 22nd August in the thread "Obtaining
the files modified/created after a failed/successfulbuild of CVS
repository".

> For reasons *not* to use CVSNT, see the posting from Michael 
> Haggerty on
> August 20th (Message-ID: <address@hidden>).
> 
> (Waiting for Arthur to come up with reasons to use CVSNT ;) )
> 

I don't always read the list and I was travelling on those days, so I'll
reply now because I think Michael's questions are good ones.

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. 

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.  CVSNT and CVS and any other
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.

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/

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.

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

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


2.
> But who do you suppose would document the format?  CVSNT is IMHO a
> project with a mostly commercial character, and the commercial
> supporters obviously have no interest in publishing the 
> information that
> will help you extract your data from their product and move on to
> another VCS.  True, it is open-source, so anybody could in principle
> analyze the source code to figure out the format.  But in 
> practice that
> is vastly more work than reading decent file format documentation.
> 
> This conundrum is one of the strongest reasons that people 
> should think
> three times before putting their precious data into a commercial
> system--they may get locked in and not be able to get their data back
> out again in a reasonable format.
> 

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,
however I have people asking me every day for merge tracking, access
control, repository caching, user-defined change sets, web based
interfaces, webdav support, defect tracking integration etc etc.  It is
logical and reasonable that with limited resources we spend our effort
on the things that are most requested.  

Of course CVSNT is an open source project so there is always the option
for someone motivated enough to spend their effort on things that we do
not consider as high a priority.

3.

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

OK- it's true I have heard some people move form CVSNT to SVN, but to
date every time I ask them for the business driver or the technical
limitation of CVSNT that SVN solves - there is no reply, in the cases I
have pursued it - the reason always comes down to 'fashion' - the
developers want to use the latest coolest gadget.  

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.  For this reason our EVS project (previously CVSNT
3.x) supports SVN clients as well as CVS and CVSNT clients (there will
be a new beta later today that I'll be announcing more widely).


In Summary:

These questions of Michael's, as with any other CVSNT question should be
asked on the CVSNT newsgroup.  

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.  This is the sort of thing journalists regularly get
into trouble over - not verifying their sources and not requesting
comment/verification (hence Steve Jobs' obituary the other week and UA's
share price crash).

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 and that we
listen to our users and solve the problems that they are asking to be
solved.  To me and all our customers and open source users they are
great reasons to use CVSNT.

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.  

What concerns me is finding people who want 'more' features than is in
CVS who do not realise that they can have those additional features with
a very simple and straightforward migration to CVSNT (since there is no
need for a cvs2cvsnt migration and scripts/commands/training are mostly
the same) are encouraged to switch to systems that are less mature, with
significant migration costs and less features but primarily with no
business benefit.

Regards,


Arthur Barrett