Is it possible to always overwrite local changes when updating from SVN?

Question

I have a file in a Subversion repository which changes almost every time it's opened in the IDE, thus creating conflicts on almost every update.

Is it possible to force SVN to always overwrite the local file with the one in the repository, even if there are local changes?

EDIT: It's a VB6 project file. Those contain GUIDs of the referenced ActiveX classes and their local file names. When a project is opened, the local file names are automaticall updated. It has to be under version control because the application cannot be built without it.

Answer 1

Well, you could always use checkout istead of update.

I'm not 100% sure, but as SubVersion only stores diff between files, I'm not sure you could to that. You could also use revert to your whole local repository.

Answer 2

First of all, if this file is changing every time you open IDE, it probably shouldn't be in version control. You should remove it and add it to ignore list.

IF you want to reject local changes before updating you must do a revert before update. SVN itself won't do it, you need to do it manually.

Answer 3

I guess that this is a file, which is always dynamically created/modified by your IDE.

I think if you add this file to the svn:ignore settings, this would better fit your needs. Look at the svn-configuration for more details. This setting makes your SVN ignore this file on adding or importing. With it you could also keep your local changes to the file, in case you have the necessity to do so at one point.

Answer 4

Updated: Since the file you describe is auto-generated, your best bet is to unversion the file and let each working copy have an independent copy. You don't have to worry about the project building without it, since VB will re-create the file when needed (right?). If you're using a continuous integration or other build server, then just keep a copy of the file on your build server, or even a copy in SVN (named differently so it doesn't conflict) that is appropriate for your build server, and modify your build process to rename the file as is first step.

For example, assuming your file is named "foo", you can keep a file "foo.example" in SVN. Then when you check out the project for the first time on any given machine, the first thing you have to do is rename "foo.example" to "foo", and then open your IDE. The IDE will modify it, but your modifications will stay local. So they won't be affected by updates, and if you put "foo.example" in your svn:ignore list, you won't have to worry about accidentally checking it in. The only drawback is that it makes your initial checkout slightly more involved, but that seems like a small price to pay.

One good rule of thumb is that if you have any files whose contents can be completely generated from other files in the repository, then they probably don't belong in the repository. Instead, either leave them out completely, or replace them with a script that generates them as needed.

Answer 5

Firstly, I feel sorry for you for having to work in VB6.

Secondly, I suppose what you really need to do is delete the file before you update. So in this case, you could have a bat file called 'do update', and you just double-click that, instead of actually using TortiseSVN (or whatever) to do the updates. You make this bat delete it, and then, unsurprisingly, update.

Incredibly lame, but I do see your problem that the file needs to be in source control, yet you want to disregard general changes unless explicitly committed.

Answer 6

Is it possible to force SVN to always overwrite the local file with the one in the repository

That would be a bad idea. VB6 project files do contain information that needs to be versioned. For example, a line with a file reference is added there whenever you add a module to the project. Therefore you should not just automatically discard any local changes made to it.

Your problem is with the commits, not the updates: the best way to avoid conflicts is by not committing the unwanted changes made by the VB6 IDE.This can be achieved by educating your developers to actually review the changes they are committing. In TortoiseSVN it is quite easy to inspect the changes to each file from the commit dialog, and revert changes on a line by line basis.

Reviewing changes when committing is something that you should be doing anyway. And I'd argue that it is even more important for changes that are made semi-automatically by an IDE. You need to keep control over what is happening to your code base.