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

Re: Huge repository

From: Nico Kadel-Garcia <nkadel_at_comcast.net>
Date: 2006-08-21 14:36:03 CEST

Zsolt wrote:
> Hi
>
> One of our customers consider to use SVN to mange a large code (180
> GB) for a mid-medium size team. Few people with a lot of code, many
> variants from the code for diiferent "product" variants. The
> commercial CMS tool providers told us that this could be a problem
> for SVN.
>
> Does anybody using SVN with >=180GB repository? Can SNV handle this
> effectively for a team of 50 developers?
>
> Another aspect where he needs more confidence in SVN is the question
> if SVN supports a more stringent way to develop software. The ongoing
> development process looks like this: Small team, lot of code, many
> internal deliverables: some one checks out a file, does his work and
> checks-in again, the release is managed by labels. Another project
> can now use this release via a "use item". Typical question for him
> is: Is everything which was in work already checked in.
>
> Can SVN manage such process together with large repository?
>
> Zsolt

A repository that big, I haven't tried. Dealing with good code check-in
procedures, though, is straightforward, You need to set sensible, working
policies on what a branch is, what a tag is, and who can put things in
trunk, with the particular procedures for merging to and from trunk
well-defined.

Releases should always be done with tags: they're easy to make, and can
easily include particular tags for other software components with
svn:externals.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Aug 21 14:38:00 2006

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.