On Apr 12, 2005, at 12:00 PM, ed.wittmann@fiserv.com wrote:
> 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?
svndumpfilter will allow you to do a dump/load cycle that will filter
out specific paths from the repository. There is currently no way to
get rid of unwanted files without dumping and reloading the repository.
-Bill
>
> -----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:26:53 2005