Organizing SVN reposities

[Han The Man <ha...@hotmail.com>]

Dear SVN experts,

I'm in the process of implementing SVN in our company, along with ViewCVS 
and TortoiseSVN.

In that regard, I have a couple of questions:

1) I'd like to put everything we have under version control - including 
source code, documentation (MS Office files, etc) and binary files for 
release to customers.  So there will be many large, binary files. Any 
problems with this approach?

Should we, due to the potential large size of all project files, use one 
repository for each project, one repository for related projects or just one 
repository? Any suggestions would be welcome.

3) Some releases (or branches) of a given product may depend on other 
versions of 3'rd party libraries than other releases. Is it reasonable to 
put even these libraries in SVN? It would be nice to have everything needed 
by a given release in a single place. Again, I suppose size would be a 
problem?

P.S. Thanks for a FANTASTIC scm system. For us, SVN means a most welcome 
goodbye to CVS and SourceSafe.

_________________________________________________________________
MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. 
http://join.msn.com/?page=features/virus


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Organizing SVN reposities

[Ben Collins-Sussman <su...@collab.net>]

"Han The Man" <ha...@hotmail.com> writes:

> 1) I'd like to put everything we have under version control -
> including source code, documentation (MS Office files, etc) and binary
> files for release to customers.  So there will be many large, binary
> files. Any problems with this approach?

Svn handles binary files just fine, much better than cvs.  But
remember that svn can't permanently delete a file.  Unlike cvs, you
can't just go into the repository and blow away a huge RCS file for
some customer-binary-release.  For now, the svn repository only ever
gets bigger.  

So versioning binary files is fine... but do you *really* want to
version release tarballs?  It might be better to throw them on a
normal fileserver, especially if they're a generated thing.


> Should we, due to the potential large size of all project files, use
> one repository for each project, one repository for related projects
> or just one repository? Any suggestions would be welcome.

Read the first 5 paragraphs of this part of the book:

  http://svnbook.red-bean.com/html-chunk/ch05s06.html#svn-ch-5-sect-6.1


> 3) Some releases (or branches) of a given product may depend on other
> versions of 3'rd party libraries than other releases. Is it reasonable
> to put even these libraries in SVN? It would be nice to have
> everything needed by a given release in a single place. Again, I
> suppose size would be a problem?

Maybe.  Nothing wrong with placing the 3rd party libraries in svn.
On the one hand, if they're not going to change over time, it may not
be worth the space.  On the other hand, it might be more convenient
for users not to have to gather libraries from different places.  You
might want to take a peek at the 'vendor branches' part of chapter 6.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org