On Mon, Nov 13, 2017 at 02:11:08PM -0500, Bo Berglund wrote:
> On Mon, 13 Nov 2017 19:03:07 +0100, Stefan Sperling <stsp_at_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.
Received on 2017-11-13 23:11:17 CET