Jorge Uriarte wrote:
> I've just stumbled into a problem I really never thought I would.
> I'm in the need of 'obliterating' some files that pose a privacy
> concern on some of my clients. I need to remove every trace of the
> content of this files; I don't care if the nodes survive the wiping
> off, but I need them 'cleared'.
>
> My repo (fsfs) is nowadays +10G (great performance, btw!), and so
> manually editing a dump scares me in some way, but I don't think I
> have any other chance, have I?
>
> The offending files must be spread along the repo, because they've
> been in there for 9 months, and we've branched several times since
> then, so I don't trust me enought to use a list of svndumpfilters
> (btw, some months ago I was unabled to filter a big repo, because of
> memory problems).
>
> My process so far has been:
>
> 1- 'svnadmin dump' of the repo -> I've got a +10G file.
Hmmm, I'd first have split that into revisions before that file was
added and revisions after it. Just dump from 0 to the one before you
added the file and you should be good.
> 2- split -b100m -a3 -d -> I've got files I can afford to 'edit'.
Well, for the rest I'd rather use incremental(!) dumps of smaller
ranges.
> 5- cat the fragments together again.
> 6- Load the new dmp file in a newly created repo.
You can supply several arguments to cat and directly loat that into
a new repository.
As for the editing of the raw dumpfile, I'm not really confident
enough to give advise on this topic, but I do know that
a) The data is not encrypted, so you should be able to use grep in
order to verify that the data is gone.
b) SVN uses a copy-on-write algorithm, so if you clear the origin of
a file you automatically erase all unmodified copies thereof.
HTH
Uli
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jan 19 09:12:54 2006