[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Copy and Reduce the size of SVn repos

From: Tony Sweeney <sweeney_at_addr.com>
Date: Sun, 08 Mar 2015 20:31:15 +0000

On 03/08/15 16:42, Branko Čibej wrote:
> On 08.03.2015 09:35, Nico Kadel-Garcia wrote:
>> On Sat, Mar 7, 2015 at 11:57 PM, Rajesh Kumar <Rajesh.Kumar_at_jda.com> wrote:
>>> I have one Huge SVN repos which is around 1TB in terms of size. I have two
>>> requirement as follows and i would like to know the best approach to be
>>> followed to save time and effort.
>> According to the doctrine of "there shall be no obliterate command,
>> the record must be kept absolutely pristine at all costs, praise the
>> gospel of all history matters!",
> Heh, I have to ask, where did you find that doctrine? There's no such
> thing. It's all a lot more mundane: First, you have to get people to
> agree what "obliterate" actually means; there are about five meanings
> that I know of. And second, all five are insanely hard to implement with
> our current repository design (just ask Julian, he spent about a year
> trying to come up with a sane, moderately backwards-compatible solution).
> -- Brane
root_at_fractal:~ # p4 help obliterate

    obliterate -- Remove files and their history from the depot

    p4 obliterate [-y -A -b -a -h] file[revRange] ...

        Obliterate permanently removes files and their history from the server.
        (See 'p4 delete' for the non-destructive way to delete a file.)
        Obliterate retrieves the disk space used by the obliterated files
        in the archive and clears the files from the metadata that is
        maintained by the server. Files in client workspaces are not
        physically affected, but they are no longer under Perforce control.

        Obliterate is aware of lazy copies made when 'p4 integrate' creates
        a branch, and does not remove copies that are still in use. Because
        of this, obliterating files does not guarantee that the corresponding
        files in the archive will be removed.

        If the file argument has a revision, the specified revision is
        obliterated. If the file argument has a revision range, the
        revisions in that range are obliterated. See 'p4 help revisions'
        for help.

        By default, obliterate displays a preview of the results. To execute
        the operation, you must specify the -y flag.

        By default, obliterate will not process a revision which has been
        archived. To include such revisions, you must specify the -A flag.

        Obliterate has three flags that can improve performance:

        The '-b' flag restricts files in the argument range to those that
        are branched and are both the first revision and the head revision
        This flag is useful for removing old branches while keeping files
        of interest (files that were modified).

        The '-a' flag skips the archive search and removal phase. This
        phase of obliterate can take a very long time for sites with big
        archive maps (db.archmap). However, file content is not removed;
        if the file was a branch, then it's most likely that the archival
        search is not necessary. This option is safe to use with the '-b'

        The '-h' flag instructs obliterate not to search db.have for all
        possible matching records to delete. Usually, db.have is one of the
        largest tables in a repository and consequently this search takes
        a long time. Do not use this flag when obliterating branches or
        namespaces for reuse, because the old content on any client
        will not match the newly-added repository files. Note that use of
        the -h flag has the side-effect of cleaning the obliterated files
        from client workspaces when they are synced.

        If you are obliterating files in order to entirely remove a depot
        from the server, and files in that depot have been integrated to
        other depots, run 'p4 snap' first to break those linkages, so that
        obliterate can remove the unreferenced archive files. If, instead,
        you specify '-a' to skip the archive removal phase, then you will
        need to specify '-f' when deleting the depot, since the presence
        of the archive files will prevent the depot deletion.

        'p4 obliterate' requires 'admin' access, which is granted by 'p4

root_at_fractal:~ #

As I recall, this was feature request #13 after Perforce was released, and was implemented the best part of 15 years ago. As near as I can tell it's architecturally impossible to implement in Subversion as a consequence of some of the initial design choices. Subversion has served me well, but this has been a glaring misfeature since its inception:


Received on 2015-03-08 21:33:22 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.