On Tue, Dec 5, 2017 at 8:07 AM, Branko Čibej <br...@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*.
