Post by Bo BerglundOn Sun, 12 Aug 2018 03:26:38 -0400, Nico Kadel-Garcia
Post by Nico Kadel-GarciaIn practice, I may have a long-term better idea for you. Split the
projects, each into their own much smaller repository with only its
own history. This is also the only good chance you'r likely to get, to
*discard* inappropriate binary files, files that accidentally were
stored with passwords, and seriously obsolete branches.tags, or even
projects altogether.
Our SVN repositories are organized in a similar way as the previous
CVS repositories were. I migrated the lot back in January and I had to
decide on the organization back then. We had about 10 CVS repositories
each with a lot of modules (= top level directories). Each repository
had different permission settings to allow some employees access while
denying all others.
To implement a per-project repository in SVN would lead to a
management nightmare as far as I could tell, first during migration
and second in operation when developers would add their projects to
SVN.
Do you really think so? I've grown very reluctant to mix many projects
into one repository. It only takes one mistake to commit 50,000
somewhat bulky files into a branch, copy or merge *one* file from that
commit into the master before you clean up, and burden the whole back
end database, and every checkout of master with that overwhelming
commit message. Smaller, more modular projects can be a very large
advantage in source control systems. I saw it.... a year ago? When
someone started loading their python "virtual environments" into a
repo, Hilarity ensued when someone didn't rea;oze tjat "pip install"
will merrily replace your core python if it detects the right version
dependencies.
Post by Bo BerglundHow could I enforce the permission restrictions in such a scenario?
repository1
|- project1
| |- trunk
| |- tags
| |- branches
|- project2
| |- trunk
etc...
repository2
|- project3
| |- trunk
| |- tags
| |- branches
|- project4
| |- trunk
etc...
I hope you don't mind that I numberd the projects individually in your
list. svnserve.conf supports having multiple groups, or admins, with
matching read and write access. It's possible to write a group for
each department, or a group for the sys-admins, that retains
administritive privileges for a set of repositories or all
repositories. Where it can get trick is when you want the people who
can *read* project1 to always, without extra fuss, include everyone
who can write half of the other projects.
Fortunately, read and write are handled distinctly, and modern LDAP
and NIS and other network compatible group privileges can *contain*
groups in other groups. So the project owner the group that owns, say
everyone in that oveseas qa group, gets write access in the
"offshoreqa" group. That group can be assigned read access to any or
all other projects individually or as part of a hierarchy of groups
and privileges. I don't recommend getting too cutesy with this. But
most of us need to control access privileges anyway, and spreading it
out to multiple svnserve.cnf files mans they can be managed
distinctly. Different project, different config file, which may match
others but doesn't have to. And my attempt to update permissions for
repository1 doesn't accidentally screw up access to all its underlying
projects.