tags:

views:

1190

answers:

3

What, someone in my team made a "mistake" to delete several files in the current revision of the team repository. Is possible to update the current local version to the head revision? When I click on commit, subclipse doesn't recognize the missing files to upload them.

Thanks in advance,
rAyt

+1  A: 

Take a copy of the deleted-in-SVN files from your revision somewhere (e.g., a temporary folder on your desktop), then update (which will remove the original files, as per your coworker's committed delete action), then move your copies back and commit them back into SVN.

JeeBee
This approach will lose the historical connection to the accidentally deleted file and will store the same file (content) twice in the repository unless you are using at least svn 1.6 on the server.
bendin
A: 

I would do the following:

Find the revision number before the delete... do an svnadmin dump -r1:[goodrevisionnumber here] > file.dump.

Then, create a new repository, "svnadmin create [repository name]" and then load the dump into the new repository. "svnadmin load [newrepositoryname] < file.dump.

Then, check out this revision, and copy the files from the old checkout into the new one and commit.

tardomatic
do we loose all previous revisions then?
Henrik P. Hessel
nope... when you do the dump, you specify from revision 1 to the good revision. when you do the load it will actually commit each and every previous commit again.
tardomatic
that did it! thanks
Henrik P. Hessel
not a problem :)
tardomatic
+5  A: 

Oh, for the love of Pete! The answers thus far have been -- at best -- misleading.

From your question, it sounds like you were trying something like this:

svn update -r8
# ok, I can see the deleted file now
svn commit -m "I want r8 to be newest"

Except that won't work. There are no modifications to commit. You can update to older revisions, but you can't make changes there. You can't change the past. You can only commit a new revision, undoing the damage.

Ok, let's assume your repository is at svn://repo. Here, a simplified example in which the folder trunk contains two files, "a", and "b". Let's call this revision 8 (r8).

trunk    # working copy of svn://repo/trunk
    a
    b

J.R. Hacker, slips up and accidentally deletes b:

svn rm b
svn commit -m "oops"

Let's call the resulting commit r9.

So, the next time you update from the repository,

svn update

trunk
    a

b vanishes! Panic? No. This is a version control system. Anything that's been checked in can be restored. Here are two possibilities:

Just copy the file from an older revision, i.e. the last revision where it still existed: 8.

svn cp svn://repo/trunk/b@8 .
svn commit -m "restored b from revision 8"

The more general solution is to use a merge. you can use this technique to undo more than just a stray deletion.

svn merge -r9:8 . .
svn commit -m "reverted the changes made in revision 8"

The way to read this merge is:

First figure out what changes need to be made to get from r9 (back) to r8 of the repository folder (svn://repo/trunk) associated with the current directory (the first "."). Now, perform those changes on the working copy in the current directory (the second ".").

There's a more convenient syntax if you're just reverting a single change:

svn merge -c-8  . . #note the minus sign before the 8

If you're not using svn from the command line, poke around your tool a bit, you're sure to find something. TortoiseSVN, for example has the handy "revert changes from this revision" when you open a log from a working copy.

bendin
It sounded to me like someone else deleted the files, he hadn't updated and still had the files in his local repository, and he wanted to somehow commit them 'over' the previous commit, which of course wouldn't work. Yes, a merge works. Yes, taking a copy of his local files, updating, and putting them back works. Please leave comments when you moderate down.
JeeBee
In subversion, there's no such thing as "local repositories" there is only one repository and user's *working copies*. An accidental svn delete on a part of a *working copy* that has not been committed can be undone with svn revert.
bendin