subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mun Johl <mun.j...@kazan-networks.com>
Subject Re: Importing from a working copy ... bad idea?
Date Fri, 19 Apr 2019 15:42:24 GMT
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-2019@ryandesign.com<mailto:subversion-2019@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

Mime
View raw message