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

Re: SVN Security

From: John <jsparrow_at_ecclescollege.ac.uk>
Date: 2005-07-17 12:04:24 CEST

Calvin <szguoxz <at> hotmail.com> writes:

> I specified fsfs as the repository type when created repository. But when I
> check the repository after check in files, I still see a db folder, with one
> file a rev, instead of one file per real file. Is this normal?

Yep, the format is still binary and bespoke. It's just not using a third party
db layer.

> Also, I see a problem of rev folder. If I reach 10,000 revs, there will be
> 10,000 files under one folder.

That's a (slightly) more reasonable concern. When you get to 50,000 revs, see if
it's a problem - only time will tell! If it is, dump and reload into bdb.
Hopefully someone will write a nice svnadmin feature to merge rev files, so
instead of:


we have:


> Another interesting feature of subversion is its binary file processing.
> Anybody tried to save a SQL server DB in it? Just wondering whether it's
> smart enough to just save the difference of the DB. If I zip the db and
> save it, how will it do then!

SVN diffs binary files too. I occasionally store SQL Server backup files in the
repos (as well as exe's). But I think it's better practice to save the scripts
and version control them (you can see what's changed, run 'blame' etc).

Zipping might not be a great idea. Removing latency in the data will (I guess)
tend to increase the size of the diffs. Your repository may grow more quickly
that if raw backup files were stored.

Personally though, I'd keep db backups out of the repository - or have them in a
seperate webDAV repos folder (see the manual) which you can purge periodically
to stop excessive growth.

Version controlling whole db files is flawed. Its not only difficult to view
changes between versions, it ties the current data into the version (not just
metadata). If I wanted version controlled data I'd dump it to XML and put that
into the repos. Or (more generally) design the db so it preserved old data


To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun Jul 17 12:06:34 2005

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.