Based on past obliterate discussions, my group may actually win in the "most
disk usage" category. :)
Due to influences outside our control, we have need to switch source control
systems near the end of the year, and after evaluating both commercial and
non-commercial packages, Subversion (coupled with svk for the offline and
merge capabilities) is up near the top of our list.
For our projects, ALL source assets go into the SCM tool. This allows us to
have a one stop shop for all assets needed to reconstitute the target build
at any point in history. However, the target building process can take a
very long time, so we also commit the targets at the same time as the source
assets. Any past build can be obtained quickly, and we aren't tied to a
"build of the day" type scenario. It has been a very effective system for
us.
The entire checked out directory tree for one of our projects (half
finished) is around 7 to 8 gigabytes (last I checked a few months back). In
a nutshell, it is broken down like so:
* Project Root\
* Raw Assets\ - Around 4 gigabytes.
* Source Code\ - A couple hundred megabytes.
* Final Target\ - Around 2.5 gigabytes.
* Tools Binaries\ - Several hundred megabytes.
We use a considerable number of branches, too. Most are private user
branches, but some are feature branches.
In the past, our server has not had enough disk space to keep up (also out
of our control). I'm told high-end industrial hard drives aren't exactly
cheap. Near the end of the last two projects, we were obliterating old
revisions like crazy to have enough disk space. Of course, we didn't want
to and it caused us some grief at times, but there wasn't a choice. Over
the lifetime of the project, we had accumulated a history of 500 to 600
gigabytes. We only had half that on our server. :(
We have more disk space now, but we are already worrying about running out
down the road.
A dump/load of the database won't work, as it can't filter out old
revisions. Worse, a dump/load of a 500+ gigabyte repository would cause a
LOT of downtime.
All said, we want to put in another request for a Subversion obliterate. I
don't see it on the Roadmap, but I am aware of a bug in the Issue Tracker.
Reclaiming disk space is huge.
This isn't a deal breaker. I just don't know what the workaround would be.
We are very interested in continuing to store ALL of our assets in source
control. I've been investigating this for a while, but at this point, my
best course of action is to solicit the input from people way smarter than I
am (that's all of you... ;) ).
(As an aside, most of our people do not need all of the Raw Assets, but they
do need some. For this purpose, I have an extension to svnserve.exe and
svn.exe that allows for a client-side file to define a "mapping" of visible
and invisible directories. It is very Perforce-like. I can specifically
isolate the 100 megabytes of Raw Asset data I need without grabbing almost 4
gigabytes of fluff. When Subversion 1.2 comes out, I'll update my changes
and submit it as a patch, for those who care.)
Thanks for everybody's help in advance.
Josh Jensen
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Apr 12 07:15:55 2005