"Han The Man" <hantheman12@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
Received on Tue Jun 17 17:45:57 2003