2

A few weeks back, our freemium subversion host sent us a message that we were over our size limit. After a few attempts to fix this (and realizing that it's not possible to shrink a repository without doing a dump->load cycle and pruning things,) we decided it was time to move to a new host with more lenient size limits (and migrate to git at the same time.)

However in the interim, we were locked out to "read only" access - which was unfortunate because there were some important local changes that hadn't been checked in. So I decided to take drastic measures and prune out older server revisions through the dump->load cycle method to get us up and working again so we could get our local modifications working. I actually dumped everything but the latest revision (r525) after making a local backup of everything.

This all worked - after a lengthy process involving the host's help, I've successfully dumped->reloaded our repository, and it's at revision 1.

However, now our clients are refusing to update our existing working copies, because they think they're working copies of revision 525:

svn: A reported revision is higher than the current repository HEAD revision.

So the question is: is it possible to "fix" my working copy to think it's at revision 1?

I realize I could just checkout a new working copy - but again, we have some local edits and would like to get those integrated if possible.

AlG
  • 14,697
  • 4
  • 41
  • 54
Aaron San Filippo
  • 43
  • 5

3 Answers3

0

Your safest bet is probably to create a patch (or several patches - if we are talking about changes in multiple working copies) with the changes - this can be done "offline", without contacting the repository. Then check out a new working copy and apply the patch(es) to it.

You create a patch with svn diff > patch.diff and apply it with svn patch.

As to the problem with binaries: you can write a script that would recursively copy modified binaries to the new working copy. You can create a list of modified files with svn status and then filter them out by extension or other properties.

malenkiy_scot
  • 16,415
  • 6
  • 64
  • 87
  • Thanks, this sounds promising. I guess I'm trying to understand how the diff works - svn is comparing my local copy to the new (revision 1) version? – Aaron San Filippo May 29 '12 at 17:40
  • No: svn is comparing your working copy with the last checked out revision (`BASE`), which is in your case is from the old repository. That revision is stored *locally* with your working copy to allow you to do many basic operations (such as `diff` and `revert`) offline. If I understand you correctly `BASE` in the previous repo == r1 in your new repo, that's why this approach should work. – malenkiy_scot May 29 '12 at 19:33
  • Yes, that's correct. If I'm understanding from other documentation as well though, svn diffs won't include binary files. Is there a solution that would cover all types of changes and not just text files? – Aaron San Filippo May 29 '12 at 23:03
  • If you have just a few binary files and/or they are localized to a few directories - do it by hand. Another possibility is that you can build the binaries from the sources. If none of the above reasons apply - you are not using SVN correctly (see [this answer](http://stackoverflow.com/a/531464/1178189), for example). – malenkiy_scot May 30 '12 at 07:18
  • I'm doing game development, and have dozens of non-executable binary files. Are you really suggesting that these shouldn't be in version control? – Aaron San Filippo May 30 '12 at 18:40
  • No, I am definitely not saying they should not be. You can even very plausibly argue that the tools you are using also should be under version control (so that in the future you do not have to look for them). What I'm saying is that binary resources should be highly localized and not mixed with text (there are various strategies to do that). In any case, what's done is done; please do not take my comment personally as I did not intend it to be personal. – malenkiy_scot May 30 '12 at 19:08
  • Not taken personally, I'm just looking for solutions here :) The organization of where my binary files live is largely up to the frameworks that I work with. In the end, I ended up doing this by hand. Going forward, hopefully I can find a nicer solution with Git... Thanks for the help! – Aaron San Filippo May 30 '12 at 19:24
  • Ok. If it indeed helped (not sure if it did - as you ended up doing it by hand), please consider [accepting the answer](http://meta.stackexchange.com/a/5235/177981). – malenkiy_scot May 30 '12 at 20:21
0

Delete the hidden .svn files from the conflicting folders and update to HEAD. It will keep the local changes.

laffuste
  • 16,287
  • 8
  • 84
  • 91
0

With newer versions of Subversion you can use sqlite to modify the working copy database, this is rather dangerous and you may completely break things. If you want to give it a try here is how.

First find out what the latest revision is in the remote repository is at:

$ svn info https://example.com/svn/project/trunk/
Path: trunk
URL: https://example.com/svn/project/trunk
Repository Root: https://example.com/svn
Repository UUID: fdecad78-55fc-0310-b1b2-d7d25cf747c9
Revision: 86002 <-- This is the value you want
Node Kind: directory
Last Changed Author: user@example.com
Last Changed Rev: 49367
Last Changed Date: 2008-05-23 17:01:34 +0100 (Fri, 23 May 2008)

then edit the sqlite DB and change the revision to be the latest seen in the repository:

cd .svn
$ sqlite3 wc.db 
SQLite version 3.7.13 2012-07-17 17:46:21
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> update nodes set revision = 86002 where revision > 86002;
sqlite> .exit
$ cd ..
$ svn up
Updating '.':
At revision 86002.

You may also need to run this SQL if recent commits were made in your project:

update nodes set changed_revision = 86002 where changed_revision > 86002;
Matthew Buckett
  • 4,073
  • 1
  • 36
  • 28