On Mon, Nov 13, 2017 at 12:16:34PM -0500, Bo Berglund wrote:
> Planning to move from CVS to SVN, but I am not sure how to handle the
> transfer....
> 1) We have used CVSNT since 2001, but we have not used any specific
> CVSNT additions that I know of. THe CVSNT version is 2.5.03.2382
>
> 2) The server handles 6 different repositories organized as
> subdirectories below E:\CVSREPOS
>
> 3) The permissions are different for these repositories and are
> handled through Windows file system access permissions via AD groups
>
> 4) Some projects (especially in the PC repository) are defined in the
> CVSROOT/modules file as a combination of files/folders from different
> physical trees.
>
> 5) The repositories total 32787 files with a combined size of 7.9 GB.
>
>
> Now I wonder how I should go about migrating to SVN? What I have read
> indicates that the cvs2svn script does not use the information within
> the CVSROOT admin directory of each repository, so I guess I have to
> re-create something similar in SVN after the files have been
> converted?
cvs2svn worked fine for me during a CVSNT->SVN migration some years ago.
Subversion stores access permissions in a special configuration file
on the server, so you'll have to re-create users, groups, and their
access rights in the SVN server's configuration:
http://svnbook.red-bean.com/nightly/en/svn.serverconfig.pathbasedauthz.html
Generally, I would recommend scripting the entire data migration process such
that it is repeatable. Then you can iterate the conversion process and allow
users to test the new system well before it goes live. Keep iterating until
you get a result that is acceptable for production use, then switch.
> Does SVN have a concept like the modules file such that one can create
> virtual modules for checkout where some files/folders are shared
> between projects (common code)?
You could use externals for this purpose:
http://svnbook.red-bean.com/nightly/en/svn.advanced.externals.html
These can be configured post-migration in SVN, and/or inside SVN as a
post-processing step during scripted data migration. Externals basically
configure a 'repository URL' to 'local directory' mapping which the
SVN client follows when it performs a 'checkout' or 'update'.
As noted in the SVN book chapter I linked above, externals should
always use 'relative' URLs rather than absolute URLs, where possible.
Relative URLs are resilient to potential future changes of most URL
components, such as the SVN server's hostname.
I would discourage use of externals to handle complicated dependency chains.
Externals are good enough if the dependency relationships are of a simple
variety. But if you find yourself using more than a handful of externals,
you're probably better off using a dependency management tool that works
above the version control system (e.g. in the build system).
> Can I use Windows Server 2016 as the server for the SVN repository(s)?
Yes. See http://subversion.apache.org/packages.html#windows for a
couple of options.
Received on 2017-11-13 19:03:41 CET