# SVN question - purge all but latest



## Beeblebrox (Feb 10, 2014)

I'm using SVN for ports and source.

How does one delete/purge all records of version changes except for the latest version? I keep finding solutions like backup/dump the latest revision then restore it else were, but this does not make much sense for a pull repository.

Regards.


----------



## ljboiler (Feb 10, 2014)

Are you thinking that somehow your "pull" of the ports or source tree is wasting space on your machine with all that history of version changes?  Well, don't worry:  svn keeps that history only on the repository server; on your local machine all you get are the files and just enough information to know exactly which versions of the files you have.  If you want to view the history of changes to a file, you must have a working network connection back to the main repository.


----------



## Beeblebrox (Feb 10, 2014)

Thanks. I don't know anything about the internals of svn.

It's not the HDD space that bugs me, it's when I have to tarball an SVN repository (don't ask why). The files get tarred fairly quickly, while the .svn folder takes almost twice the amount of time.


----------



## ljboiler (Feb 10, 2014)

svn has a "pristine" copy of each checked-out file in that .svn directory; that's why there's a long pause there if you archive the whole thing.  That local clean copy allows diffs to be done between your working copy and the repository version that was checked out _without_ having a network connection.


----------



## kpa (Feb 10, 2014)

That's because the .svn directory contains a very big hash table of all the commits in the repository laid out as many directories and files. Only the references to the commits though, not the actual commits unlike let's say Git. It's slow to process such directory structures because there are many small files per each directory. I'm not aware of any method to forget all but the last revision of a repository, it is assumed that if you have the version history you're usually interested in versions other than the latest ones.


----------



## trh411 (Feb 10, 2014)

Beeblebrox said:
			
		

> Thanks. I don't know anything about the internals of svn.
> 
> It's not the HDD space that bugs me, it's when I have to tarball an SVN repo (don't ask why). The files get tarred fairly quickly, while the .svn folder takes almost twice the amount of time.


The .svn directory is where devel/subversion keeps track of the state of all objects in the local working copy. Because of the size of the ports tree (24K+ ports) there is a lot to keep track of. I have 119K objects in my /usr/ports/.svn directory. That's about 600 MB.


----------



## Beeblebrox (Feb 10, 2014)

... and hence my question. A better title might have been: "Take a snapshot of the current version, then drop all prior version references", since as a "pull repo" user, I'm not that interested in rolling back to some date three months ago. Well, at least we have an answer for that: not for the time being.


----------



## ljboiler (Feb 10, 2014)

Perhaps then you should look at what `svn export` does:  you get a copy of all the files as they were at the time of the tag/branch/version that you specify (or the latest if you're dealing with HEAD), BUT all that internal bookkeeping data is not pulled down; what you gain in not having to deal with that being pulled down (and copied in your case) you lose in the ability to know what exact version you got of anything and where it came from.

You would end up with the same result of the `svn export` by just excluding that .svn directory from your tarball.


----------



## wblock@ (Feb 10, 2014)

`svn cleanup` can sometimes make a significant reduction in the size of the local working copy.


----------



## Beeblebrox (Feb 10, 2014)

> Perhaps then you should look at what svn export


It's been a while since I messed with svn, and I did not look up the exact terminology as a refresher before posting, but that's what I meant by:


> I keep finding solutions like backup/dump the latest revision then restore it else were



@wblock: I do run `svn cleanup` now and then, but I do that when I get svn errors (merging gnome3). I did not know that `cleanup` could also reduce archive size. Good to know and better than nothing.

Thanks everyone for the input.


----------

