Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
Hello! Tony Hoyle <tony.hoyle at march-hare.com> writes: > Oliver Koltermann wrote: > > The only thing worth noting is maybe, that the file has the > > substitution mode 'u' in the log output. Revisions 1.1 and 1.2 are > > also mode 'u'. Beginning with 1.3 all revisions have mode 'b'. > > You switched file mode to binary.. that means everyhing comes out > literally... it's a different situation (you also lose merge, > keywords, etc.). This is what I expected. We had problems with the first unicode handling CVSNT versions but never really investigated them. This is a secondary issue for us because we don't need merge or keyword features on these files at the moment. So we switched back to binary mode to just handle the version tags for these files. But as you say: Everything should come out literally - even if the file content is somehow unicodish. > 0xd0 isn't special to cvsnt at all. btw. is this the source data in > UTF8 (in which case it's the first part of a two character encoding) > or the destination data in UCS2? Please see the file I sent to you as you clearly know more about this topic than I... > > Should I change the old revisions modes away from 'u'? And how would I > > do this? (cvs admin? :-S) > > You don't want to do this as the revision deltas are stored as UTF8 > not UCS2 like the binary version will be. There's no way to safely > retroactively change the type of an old revision (maybe for some minor > changes, but definately not -ku to -kb). Okay so I will wait for the result of your test with my file before I try to corrupt the whole repository ;-) Thanks for all your work and patience, Tony. Bye, O. Koltermann.