RE: Re: CVSNT text-vs-binary

> ...
> I thought I remembered that CVSNT also added a new kind of binary "diff"
> format for storing the difference between revisions of binary files. I
> also thought that such revisions would be marked with some other "kopt"
> value. Is that right, or is "b" the only kopt value that can appear in
> CVSNT?

I think there are more, and there are also more "newphrases" for revisions. However I did not specifically use any of the extensions so that I do not already have files containing such things. I'll try doing some tests and try to guess how are these reflected into the RCS files.

Extra features/ revision headers I (vaguely) know of:
- "kopt" (compressed deltas? various character encodings for text files, 
  including UTF-16? these in addition to per-revision eol handling and 
  keyword expansion)
- "deltatype" (binary diffs? normally it says "deltatype text;")
- "mergepoint<n>" (self explanatory, I have these in my files)
- "commitid"
- "permissions"
- "filename" (renames? or just to be sure case is preserved? - the old CVSNT 
  version I use has support for renames, marked as "experimental")

And because you mentioned "more options in kopt":
I noticed in the cvs2svn code that it does comparisons like "mode == <char>" (example: "cvs_file_or_rev.mode == 'k'" in svn_run_options). This won't work if there are extra characters in "mode" than what we test for ("kv"/"kvl" for example) or when the order is not exactly the same if we compare with a string like in "mode == "kv"".

> ...
> If there is a new binary "diff" format, I suppose that means that CVSNT
> users will have to continue using --use-cvs to extract their revisions.
> Is that correct?

For binary deltas, I think yes. cvs2svn will take care of keywords and eols, right?

For other things I don't think it is sufficient. For example UTF-16 text files will have to be marked as binary in the destination repo event if they are text the source repo; unfortunately then eols and keywords will be "frozen".

> ...
> It would be great if you could put a couple of smallish CVSNT files in
> our test suite and write some tests that verify that their revisions are
> being extracted correctly. Probably these files should go into a new
> test repository under test-data. Having tests will make it clear that
> the feature works and will also prevent the feature from being broken
> inadvertently by future changes.
> 
> Given that CVSNT is apparently no longer freely downloadable, it will be
> problematic for some people (me, for instance) to run any tests that
> rely on a CVSNT executable. So if it is possible for part of the CVSNT
> support to be tested without CVSNT, that would be very helpful. Ideally,
> tests that depend on CVSNT would also somehow disable themselves when
> CVSNT isn't installed.
> ...

I'll try to do this (for now I don't know how to, but I hope I'll figure it out).

sags

------------------------------------------------------
http://cvs2svn.tigris.org/ds/viewMessage.do?dsForumId=1667&dsMessageId=3111140

To unsubscribe from this discussion, e-mail: [[email protected]].