On Sun, Aug 12, 2018 at 4:46 AM, Bo Berglund <bo.bergl...@gmail.com> wrote: > On Sun, 12 Aug 2018 03:26:38 -0400, Nico Kadel-Garcia > <nka...@gmail.com> wrote: > >>In 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. > How could I enforce the permission restrictions in such a scenario? > > So this is why I have this structure: > > 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.