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.co...@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:suresh1256...@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
