On Tue, Dec 5, 2017 at 8:07 AM, Branko Čibej <brane_at_apache.org> wrote:
> On 05.12.2017 12:42, Bo Berglund wrote:
>> I need to migrate a CVSNT server repository to SVN.
>> The CVSNT cvs executable needs to be used in the cvs2svn script in
>> order to handle the CVSNT specific peculiarities. So I need to do the
>> first step of migration on Windows.
>>
>> The CVS repository is now about 8 GB in size and some version files
>> (the ,v files) are huge since they hold a large number of revisions of
>> binary files. Some are 500 Mbytes in size...
>>
>> When done then I want to move SVN to Linux in order to get away from
>> the Windows problems.
>> So once I have the SVN repository, how can I move it over to Linux?
>> Is there some preferred method?
>
> If your repository isn't being used, just (recursively) copy the
> repository directory. The storage format and configuration files are
> platform-independent, but of course any hook scripts you have are not.
>
> -- Brane
I'd urge making a complete filesystem copy *anyway*, before beginning.
I don't know if TortoiseSVN contains this kind of utility these days,
but Cygwin certainly does contain cvs2svn, if you want to do the
transformation locally first. There are also some booby traps for old
repositories. I had one devil of a time some years back when someone
had been manually editing the ",v" files to manipulate the stored
comments, and made a mistake. When I *corrected* the mistake by
correcting the line count for the modified comment section, comments
for which there was no history left of the original comment before
editing, the engineer who'd been maintaining the system and who wasn't
supposed to be doing that anymore threw a wobbly on me. But without
the manual correction, cvs2svn could not complete.
Every major Linux has Subversion, so you should be able to bring the
raw CVS repository over. If you do cvs2svn on Windows first, there's
another booby trap. Many server grade versions of Linux have obsolete
Subversion. You may have difficulty if you do cvs2svn with Subversion
1.9.x on the Windows box, and then try to load it with Subversion
1.6.x on a RHEL or CentOS system. So I'd urge you to copy over to the
Linux system first, and do cvs2svn there.
If I may suggest, this is actually a good chance to *discard* content.
Subversion is predicated on an uneditable central repository which
*cannot* be edited. The dump and reload process used for cvs2svn is
one of the few chances to discard obsolete tages, branches, or even
accidentally stored binaries and subdirectories without discarding the
history you care about.
Also. If you want to *really* clear up spurious history, there's
another fairly dirty trick. Use cvs2git instead of cvs2svn. Flush
undesired content from the resulting git repo. Then use a "git gc
--aggressive" This prunes all loose objects which are not part of the
current "HEAD" of the repository. And you can then publish the local
git repository to a new Subversion repository. The new Subversion
repository will *not* be identical to the old CVS repository. But in
most cases, do you really care? Keep the copy of the old CVS repo
backed up, for reference and any legal liability issues.
Be aware: this violates a longstanding principle of Subversion by
discarding history. The only supported method is to do an "svnadmin
dump", with "svndumpfilter" run before feeding the dump to "svnadmin
load". But this is just the time to do that, because cvs2svn or
cvs2git effectively create the dump, and the new Subversion repository
will be treated as a new repository *anyway*.
Received on 2017-12-05 17:29:31 CET