You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by sureshkumar nandakumar <su...@gmail.com> on 2012/01/12 07:58:06 UTC
Permanent removal
Dear Expert,
Our repository size are increasing on daily basis, we were planed and
removed unused tags in SVN.
But still the size is not increased. And also whatever I have removed
all those files are still persist in earlier version.
Then there is no use of my removal.
Suppose, I would like to do permanent removal in SVN, how can it
possible and how to do permanent removal in SVN?
If I do permanent removal, how I can take those files in case if it is
require for future reference.
Please advise me with good practice.
Your suggestion is more use to me.
RE: Permanent removal
Posted by "Cooke, Mark" <ma...@siemens.com>.
> From: Ulrich Eckhardt [mailto:ulrich.eckhardt@dominolaser.com]
> Sent: 12 January 2012 08:48
> Subject: Re: Permanent removal
>
> Am 12.01.2012 09:20, schrieb Stümpfig, Thomas:
> > There may be Companywide retention policies for Document archival.
> > Working, Approved, Archived, Deleted. There might be cases where
> > deletion is required by these policies.
> >
> > Dumpfilter is just a workaround for a new command and privilege
> > (r,w,d). From what I can see, permanent delete Issues has already
> > been discussed several times. AFAIK there is no plan to implement
> > such a command. Please correct me if I am wrong.
>
> Don't top post and trim unnecessary content, please.
>
> There are actually plans to implement such a command. The feature is
> called "obliterate", doing a websearch on it should give you lots of
> info, I believe it is even mentioned in the FAQ.
I just checked http://subversion.apache.org/roadmap.html#features-most-wanted and `obliterate` was pulled from 1.7 and has also been removed from 1.8 from the roadmap.
This is not quite the same as "no plan to implement" but seems effectively the same thing for now...
~ mark c
> Greetings!
>
> Uli
Re: Permanent removal
Posted by Ulrich Eckhardt <ul...@dominolaser.com>.
Am 12.01.2012 09:20, schrieb Stümpfig, Thomas:
> There may be Companywide retention policies for Document archival.
> Working, Approved, Archived, Deleted. There might be cases where
> deletion is required by these policies.
>
> Dumpfilter is just a workaround for a new command and privilege
> (r,w,d). From what I can see, permanent delete Issues has already
> been discussed several times. AFAIK there is no plan to implement
> such a command. Please correct me if I am wrong.
Don't top post and trim unnecessary content, please.
There are actually plans to implement such a command. The feature is
called "obliterate", doing a websearch on it should give you lots of
info, I believe it is even mentioned in the FAQ.
Greetings!
Uli
**************************************************************************************
Domino Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
**************************************************************************************
Visit our website at http://www.dominolaser.com
**************************************************************************************
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte Änderungen enthalten. Domino Laser GmbH ist für diese Folgen nicht verantwortlich.
**************************************************************************************
RE: Permanent removal
Posted by Stümpfig,
Thomas <th...@siemens.com>.
There may be Companywide retention policies for Document archival. Working, Approved, Archived, Deleted. There might be cases where deletion is required by these policies.
Dumpfilter is just a workaround for a new command and privilege (r,w,d). From what I can see, permanent delete Issues has already been discussed several times. AFAIK there is no plan to implement such a command. Please correct me if I am wrong.
Regards
Thomas Stümpfig
> -----Original Message-----
> From: Cooke, Mark [mailto:mark.cooke@siemens.com]
> Sent: Donnerstag, 12. Januar 2012 08:15
> To: sureshkumar nandakumar; users
> Cc: Sureshkumar.Nandakumar
> Subject: RE: Permanent removal
>
> Hello,
>
> > -----Original Message-----
> > From: sureshkumar nandakumar [mailto:suresh1256644@gmail.com]
> > Sent: 12 January 2012 06:58
> > Subject: Permanent removal
> >
> > Dear Expert,
> >
> I'm not an expert, just another user...
>
> > Our repository size are increasing on daily basis, we were planed and
> > removed unused tags in SVN.
>
> "Tags" are very cheap copies that take hardly any space:
> http://svnbook.red-bean.com/en/1.7/svn.branchmerge.tags.html
>
> > But still the size is not increased. And also whatever I have removed
> > all those files are still persist in earlier version.
> > Then there is no use of my removal.
> >
> Correct. "delete"ing stuff in subversion does not remove the data, just
> removes the items from subsequent revisions. That is one of the main
> features of source code control...
>
> > Suppose, I would like to do permanent removal in SVN, how can it
> > possible and how to do permanent removal in SVN?
>
> You can dump the repository, run it through svndumpfilter and then reload
> the filtered dump into a new repository.
>
> http://svnbook.red-
> bean.com/en/1.7/svn.reposadmin.maint.html#svn.reposadmin.maint.tk.svn
> dumpfilter
>
> http://svnbook.red-
> bean.com/en/1.7/svn.reposadmin.maint.html#svn.reposadmin.maint.filteri
> ng
>
> > If I do permanent removal, how I can take those files in case if it is
> > require for future reference.
>
> Whilst filtering your dump, also create a different dump file with the stuff
> you "don't want", then you can load it somewhere else in future if you want
> to.
>
> > Please advise me with good practice.
> > Your suggestion is more use to me.
> >
> Personally I chose to go the multiple-repository route from the start, creating
> new repos under a parent path for all new projects. This makes it a lot easier
> to move stuff around (so long as the projects are not too intimately related,
> of course)...
>
>
> I have to say that I do not consider 100GB to be hugh these days (although
> disk prices have gone up somewhat recently due to the flooding in Thailand)
> but 1000GB disks are still relativley cheap?
>
> Hope that helps,
>
> ~ mark c
RE: Permanent removal
Posted by "Cooke, Mark" <ma...@siemens.com>.
Hello,
> -----Original Message-----
> From: sureshkumar nandakumar [mailto:suresh1256644@gmail.com]
> Sent: 12 January 2012 06:58
> Subject: Permanent removal
>
> Dear Expert,
>
I'm not an expert, just another user...
> Our repository size are increasing on daily basis, we were planed and
> removed unused tags in SVN.
"Tags" are very cheap copies that take hardly any space:
http://svnbook.red-bean.com/en/1.7/svn.branchmerge.tags.html
> But still the size is not increased. And also whatever I have removed
> all those files are still persist in earlier version.
> Then there is no use of my removal.
>
Correct. "delete"ing stuff in subversion does not remove the data, just removes the items from subsequent revisions. That is one of the main features of source code control...
> Suppose, I would like to do permanent removal in SVN, how can it
> possible and how to do permanent removal in SVN?
You can dump the repository, run it through svndumpfilter and then reload the filtered dump into a new repository.
http://svnbook.red-bean.com/en/1.7/svn.reposadmin.maint.html#svn.reposadmin.maint.tk.svndumpfilter
http://svnbook.red-bean.com/en/1.7/svn.reposadmin.maint.html#svn.reposadmin.maint.filtering
> If I do permanent removal, how I can take those files in case if it is
> require for future reference.
Whilst filtering your dump, also create a different dump file with the stuff you "don't want", then you can load it somewhere else in future if you want to.
> Please advise me with good practice.
> Your suggestion is more use to me.
>
Personally I chose to go the multiple-repository route from the start, creating new repos under a parent path for all new projects. This makes it a lot easier to move stuff around (so long as the projects are not too intimately related, of course)...
I have to say that I do not consider 100GB to be hugh these days (although disk prices have gone up somewhat recently due to the flooding in Thailand) but 1000GB disks are still relativley cheap?
Hope that helps,
~ mark c