info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: To get some information regarding CVS


From: Michael Haggerty
Subject: Re: To get some information regarding CVS
Date: Sun, 28 Sep 2008 08:56:59 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.17) Gecko/20080925 Thunderbird/2.0.0.17 Mnenhy/0.7.5.666

Arthur Barrett wrote:
> 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.

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]