On Thu, Apr 18, 2019 at 5:08 PM Ryan Schmidt <subversion-2019_at_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.
Received on 2019-04-19 06:23:39 CEST