Not to stray too far offtopic here, but what exactly would be the
current, correct, course of action in the instance that a user(s) checked
in lots of unwanted stuff, ie, the IDE, webserver, etc?
-----Original Message-----
From: kfogel@newton.ch.collab.net [mailto:kfogel@newton.ch.collab.net] On
Behalf Of kfogel@collab.net
Sent: Tuesday, April 12, 2005 12:07 PM
To: moisei@gmail.com
Cc: users@subversion.tigris.org; dev@subversion.tigris.org
Subject: Re: Another request for obliterate...
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: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Apr 12 19:09:36 2005