ed.wittmann@fiserv.com writes:
> 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?
'svn rm STUFF'
-Karl
> -----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
---------------------------------------------------------------------
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:20:48 2005