[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Importing from a working copy ... bad idea?

From: Mun Johl <mun.johl_at_kazan-networks.com>
Date: Fri, 19 Apr 2019 15:42:24 +0000

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_at_ryandesign.com<mailto: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 Subversi
on 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
Received on 2019-04-19 17:48:50 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.