On Mon, Jul 27, 2009 at 1:51 PM, Jack Repenning <jrepenning_at_collab.net>wrote:
> So we would have these Obliterate cases:
>
> 1. Utterly removing all traces that a certain file or collection of
> files ever existed in the repository. (My restatement of your first
> case.)
>
> 2. Removing obsolete data from space motives. (Your second.)
>
> 3. Selective excision of history from file or files whose prior and
> subsequent history remains intact. (Your "notable case.")
>
> Not the least of my reasons for wanting to call this a separate item
> is this: at CollabNet, we've had many customers asking for #1 and #2,
> but to the best of my knowledge not a single word has ever been spoken
> in favor of #3.
>
Software development teams that frequently check in large binary files that
are produced during the build process (or indeed checked in as part of the
development process) are candidates for desiring #3.
I don't how many development shops run into these kinds of issues let alone
with Subversion.
I do know significant space was saved in the Windows and Visual Studio
Source Depot servers was saved by obliterating these large binary files
between major publicly released milestones.
Both of these very large version control trees have a public\ directory that
contains (among other things) checked in DLL export .lib files for DLLs that
are used across component boundaries and are updated in the daily build
process. This allows parital branch enlistments for developers.
#3 may just be a hidden use case that people don't immediately think of when
thinking about obliterate functionality.
Bill
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2376091
Received on 2009-07-27 20:45:50 CEST