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

Re: One repository vs. many

From: Jason Tesser <jasontesser_at_gmail.com>
Date: 2007-06-28 23:14:53 CEST

Well different people have different opinions on whether things should live
in a single repository or multiple repos. I for one perfer one. I like the
managment of just one and have found over time that it is easier.
You can just checkout from any directory deep in the repo so there is no
real disadvantage to only having one repo.

On 6/28/07, Scott Gifford <sgifford@suspectclass.com> wrote:
> Hello,
> I'm coming to SVN from CVS, and we're looking at a few different
> hosted SVN providers. One of the differences between the different
> providers is the number of repositories you can create, which varies
> from 1 to a few to unlimited.
> Are there any big advantages to having different repositories for
> different projects versus having one big repository with a tree for
> each project? We will mostly have a large C/C++ code base, but may do
> some Java GUI work, some Web stuff, etc. all of which will be
> independent. Is there an advantage to keeping everything in its own
> repository? It's possible to check out just parts of the SVN
> repository to work on just one of those projects, right?
> Also: the hosting providers I'm looking at are wush.net, CVSdude,
> DevGuard, and hosted-projects.com. If anybody would be willing to
> privately share with me their positive or negative experiences with
> any of these folks, I would appreciate it.
> Thanks!
> ----Scott.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org

Jason Tesser
dotmarketing, Lead Programmer
Received on Thu Jun 28 23:15:05 2007

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.