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'
option.
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
protect'.
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:
http://svn.haxx.se/dev/archive-2003-01/0364.shtml
Tony.
Received on 2015-03-08 21:33:22 CET