views:

1257

answers:

2

I have a growing repository containing a dozen or so projects that I maintain using TortoiseSVN (as I am completely new to this and don't know the ins and outs yet). The space I have to hold the repository is limited so I want to back it up, then remove some of the older versions. For example, if a project is at version 50, I want to keep only 50,49,48.

A: 

There's no way to "snip" a repository at a particular revision in the manner you describe. What you could do is svn export the whole repository at the desired revision, then import it into a new repository, then replay the commits from the revisions after that from your log file into the new repository. This is not trivial.

Alternatively, if you just want to exclude some cluttered paths from your repository, and you have direct access to the file system where the repository is residing, you can use a combination of svnadmin and svndumpfilter to select the paths you want and prune all others.

Note that what you're describing is more or less against the point of Subversion: it's supposed to keep everything. If you frequently have trouble with this, consider establishing better checkin practices. Or consider using Git, which makes this sort of experimentation virtually free.

John Feminella
Branches (svn copy) in subversion are almost free, both in time and space. And starting with subversion 1.6, merges of patches between branches use representation sharing to avoid duplication of data. I have no idea what you are referring to by saying "branches are space-expensive in svn".
Wim Coenen
In general, messing around with svn-dumpfilter is far more labor-intensive than messing around with git-filter-branch and/or .git/info/grafts. I've patched svn-dumpfilter heavily to support more kinds of history editing, and it's still not a nice tool.
emk
@wcoenen: You are right. I didn't phrase that very well at all. @emk: Agreed, it's pretty awful. Nowadays I primarily use Git.
John Feminella
To be honest, I only use Subversion because I need to sync my code on various machines (home and work) and it is a nice way to do this via a USB stick. I find SVN a bit annoying though because it doesn't force checkouts and merging seems a bit dubious sometimes.
... as in when I forget to commit on one machine and change code on another. For my simple requirements, SourceSafe-type functionality was great (but SS was not very stable).
+5  A: 

Removing old revisions kind of defeats the point of version control, but you can just dump out the revisions you want to keep, then put them into a new repo, and delete the old one.

svnadmin dump /path/to/current/repo -r48:50 > svn.dump
svnadmin create /path/to/new/repo
svnadmin load /path/to/new/repo < svn.dump

Or use svndumpfilter to include/exclude the particular bits you want, etc. There also some info in the svn FAQs about removal that you may find useful.

Rich Adams
Isn't that only going to dump the specific *commits* from revisions 48 through 50? I think he's looking for the state of the repository as it was at revision 48, not just the commit there.
John Feminella
I just tried this. This doesn't do what I think the OP wants at all: it gets *only* the commits from those revisions. You don't get "the state of the repository at revision 48, followed by all commits necessary to get it to revision 50."
John Feminella
John: how are you running it? It works fine for me. It dumps fully the first revision specified, then the commits up to the last revision specified. Only if you specify the "--deltas" switch does it just dump the commits.
Rich Adams