subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tony Sweeney <>
Subject Re: Copy and Reduce the size of SVn repos
Date Sun, 08 Mar 2015 20:31:15 GMT
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 <> 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@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@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:


View raw message