up vote 1 down vote favorite
share [g+] share [fb]

I've got working copies of the same repository on two different computers (Macs). There is a file in question (let's say SomeFile.m) which shows to be at r703 in both working copies, with no local modifications. Doing svn update SomeFile.m on both sides produces no updates - it thinks it's totally up to date with the repository.

However, the two files are different. They have different checksums, and a diff shows differences that are important to the code. The file is correct in one of the working copies, but not the other.

Firstly, how do I force the incorrect file to be replaced with whatever's in the repository?

Secondly, how did this file get in this state in the first place? Through incorrect conflict resolution or something like that?

link|improve this question
50% accept rate
feedback

2 Answers

up vote 1 down vote

If one file version is the correct one, but you suspect that the version in the repository is incorrect, then see How can I force subversion to commit an unchanged file?

If you want to force a get of the files from the repository, then see Force an svn checkout command to overwrite current files.

Otherwise, just modify one of the files, save it to the repository as new revision and re-checkout on the other computer as above.

link|improve this answer
this isn't quite what I was looking for. the version in the repository is correct, and the version in one of the WCs is correct; the version in the other WC is not. What I was looking for is a way to force a refresh on the copy in one of the WCs. I'm also want to figure out how it got in this state in the first place. – Ben Collins Sep 12 '10 at 17:40
I thought I answered how to force a refresh. To figure out how it got this way may take specialized knowledge of your installation. Have you compared modification dates on the files on both machines? – harrymc Sep 12 '10 at 20:37
feedback
up vote 0 down vote

The easiest way I've found to "force" a checkout/update of a particular file is to delete that file in the working copy - filesystem delete, not svn-delete - and run an update of the working copy. The file will be restored with the version from the repo.

One way the file could have gotten into this state is that is has some local modification that went unnoticed. SVN won't commit the file without conflict resolution and it would be left un-updated, as well.

link|improve this answer
feedback

Your Answer

 
or
required, but never shown
discard

Not the answer you're looking for? Browse other questions tagged or ask your own question.