On Mon, Nov 13, 2017 at 02:11:08PM -0500, Bo Berglund wrote: > On Mon, 13 Nov 2017 19:03:07 +0100, Stefan Sperling <s...@elego.de> > wrote: > > > > >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 > > > > Thanks I will look into that more closely. > One question, though, that might be a terminology misunderstanding on > my part: > In CVS a repository is the container for a lot of different "modules", > which are top level directories below the root of the repository (or > else defined in CVSROOT/modules). > > When reading your link above I found I became hesitant as to what SVN > means by "repository", it does not look like it is a 1-1 compared to > CVS... > > I have as I said 6 CVS repositories served by CVSNT in order to > isolate files that are to be kept separate. For example the hardware > designers use repo HW for their firmware developments, Windows > application developers use repository PC and marketing uses Marketing > for their documents etc. > So in essence I have 6 different repositories in CVS language. > How does this map into SVN? > The SVN path-based authorization seems to be dealing with repositories > (modules?) within the repository (singular), all below the SVN root... > > Did I misunderstand the way SVN works?
SVN is more flexible than CVS in this regard. Because directories, rather than just files, are versioned, subdirectories of a repository can act as a home for an entire project and thus become a 'module' in CVS terms. See for instance the Apache Software Foundation's SVN repository, where each top-level directory corresponds to an apache.org project: https://svn.apache.org/viewvc Such a designation of a 'project directory' or 'module' is simply a convention put in place by users. SVN by itself won't treat any directories special in any way (this goes further; for instance, project branches and tags are also modeled as directories). So you could migrate all 6 CVS repositories into one SVN repository with one top-level directory per project, or you could create 6 distinct SVN repositories. cvs2svn supports either approach. See http://cvs2svn.tigris.org/faq.html#oneatatime If your 6 projects could ever be expected to merge code from one another, it makes sense to put them all in a single SVN repository because merge tracking occurs on a per-repository basis (because SVN is not a distributed version control system). Also, if you wish to use 'file externals' between projects, they will have to be in the same repository (this is an unfortunate implementation quirk). On the other hand, there is an administrative concern which does not concern end users: Backup and restore should occur on a per-repository basis. So if you split projects across repositories there will be less overall impact in case one of them has to be restored from backup for some unfortunate reason (such events are very rare, but should not be ruled out in a risk assessment). But if your CVS repositories aren't very large yet, then this should not be a concern.