Hello dear all,
Is not it much easier to implement "obliterate" in a way it removes
the content
of the file from the repository (for all the revisions) but does not remove
the record of this file?
I.e the obliterated files remain to appear in the repository but with
empty content.
Seems to be good for the disk usage and for the security data as well -
I hardly imagine the one keeps the super-top-secret data as a file name.
I am not in deeep aware of the svn back-end implementation but
my feeling that complication of the "obliterate" is a need to change
the structure of the nodes in the "old" revisions.
Sorry again, if I completely wrong and such an implementation is
complicate as well.
Best Regards,
Moisei.
On Apr 12, 2005 7:13 AM, Joshua Jensen <jjensen@workspacewhiz.com> wrote:
> 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
>
>
--
Best Regards,
Moisei
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Apr 12 11:32:41 2005