Hi Nathan, On Thu, Apr 18, 2019 at 09:23 PM PDT, Nathan Hartman wrote: > On Thu, Apr 18, 2019 at 5:08 PM Ryan Schmidt > <subversion-2...@ryandesign.com<mailto:subversion-2...@ryandesign.com>> wrote: >> In this whole thread we are presuming that you have a single repository >> containing multiple projects. In that case, you can preserve history. But >> another approach is to use a separate repository for each project, and if >> you're going to do that, you won't be preserving any history. While >> Subversion users freely use both approaches, it's worth seriously >> considering the single-project-per-repository approach, since that's what's >> used in git. Subversion allows you the freedom to decide where to put your >> trunk/branches/tags directories -- either at the top level, or underneath >> directories for each project, or any other arbitrary layout you want. Git >> does not allow you that freedom. You may not want to use git today, but >> maybe you will want to convert your repository to git eventually, and if so, >> it will be easier to convert single-project Subversion repositories than it >> will be to write a complicated set of svn2git rules to split >> multiple-project repositories. (We did it successfully with the MacPorts >> Subversion repository a couple years ago, but it was difficult.) > > An alternate viewpoint: Depending on what type of organization you are and > what you're developing, there is merit to a "monorepo" where all projects > (with their trunk/branches/tags) live in a single Subversion repository. It > simplifies administration, since you have just one repository to worry about, > in contrast to any DBCS (like git) which lead you down a path of > proliferation of repositories. Subversion allows to check out a subset of a > repository so you can get only the project(s) you need. You can do sparse > checkouts. It simplifies managing of code sharing between projects very > elegantly. It allows atomic commits that cross project boundaries. We used to > have six different repositories and we combined them all into one and life > has been much easier since we did that.
Many of the points you make are definitely contributing factors to why we currently only have a single repository. And maybe most importantly, we are a small company with not a lot of bandwidth to dedicate to SVN management. I think that may have been the driving force for the individuals who initially set up SVN at this company. Thank you for your viewpoints. Kind regards, -- Mun
