I got some time to download subversion, recompile it and wander through
the docs. No doubt that SVN is gonna be a great replacement and
enhancement to CVS. I am particularly interested in an area where CVS
isn't doing great: binary file repositories.
Let's say you have a project that deals with a lot of multimedia data such
as sound files, images, and other monolitic binary objects. And you want
to allow collaborative work with those files to a bunch of people.
Being long time CVS users, our first solution was to use it. But CVS gets
insanely slow when the repository gets big. I haven't clearly identified
what's happening yet, it seems that on a cvs commit it will try to fetch
all the repository files to see if they have been modified before
performing the commit. This is going to be a blocking situation for us
pretty soon, given that our target repository size is >100Mb
I have looked for open source / free software alternatives that can
provide a solution for binary repositories but didn't find any satisfying
solution. So I am looking at SVN now. If you guys know some interesting
solution, please send me the links.
Does the design of SVN have some specific features to support binary
repositories? I will try to list below the major points when dealing with
binary repositories:
- Efficient file transfer protocols. Using rsync might be of interest.
- Efficient file comparison. When deciding wether a local file is in sync
with the repository, use md5sum instead of fetching and diffing.
- versions and branches as usual in CVS.
- file locking. given that binary files don't merge, concurrency has a
reduced importance. File locking abilities would be a great bonus. Either
the intrusive way, like setting the repository to readonly and having
to specifically lock the files you are going to change, or non-intrusive
with a daemon locking the files you modify and keeping readonly the files
locked by others.
If I can just get those 4 features working, I'd be very very happy :-)
Now I'm waiting for opinions of subversions gurus wether this is part of
SVN's objectives, wether there has been some design done around that and
wether they think it would be worth doing...
regards
TTimo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:43 2006