Please read over
http://subversion.tigris.org/issues/show_bug.cgi?id=516
to see the complexities of 'obliterate', and why we haven't gotten
around to it yet. It's not impossible to implement, but some
specification work is needed first.
-Karl
Moisei <moisei@gmail.com> writes:
> 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: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Apr 12 18:42:32 2005