We have some company middleware and sometimes its difficult to find the correct version Im looking for so I often have to update to different versions to test them.

I usually checkout:

svn co svn+ssh://(username)@(ip)/srv/svn/intranet/trunk/PYTHON/<application> <local-application>

I then may update to a different version

svn update (path) -r (rev)

Most of the time after a few attempts this will cause the error Node remains in conflict

If I delete the folder and try to do a fresh checkout it just restores what I had. All I want to do is checkout a revision, I have made no changes and it still thinks there are conflicts.

Ive tried to resolve them, but nothing seems to work:

svn update -r 1586

Skipped 'inm/inm' -- Node remains in conflict
D inm/fabfile.py
D inm/test.db.bak
D inm/tests
D inm/test.db
D inm/doc
D inm/test.ini
D inm/test.sql
U inm/setup.py
A inm/inm.egg-info
A inm/inm.egg-info/SOURCES.txt
A inm/inm.egg-info/top_level.txt
A inm/inm.egg-info/PKG-INFO
A inm/inm.egg-info/entry_points.txt
A inm/inm.egg-info/dependency_links.txt
A inm/inm.egg-info/not-zip-safe
A inm/inm.egg-info/paster_plugins.txt
A inm/inm.egg-info/requires.txt
U inm/setup.cfg
Updated to revision 1586.
Killed by signal 15.
Summary of conflicts:
Skipped paths: 1 svn resolved inm/inm
Resolved conflicted state of 'inm/inm'
(venv) svn update inm/inm -r 1586
Updating 'inm/inm':
Password:
Skipped 'inm/inm/templates' -- Node remains in conflict
At revision 1586.
Killed by signal 15.
Summary of conflicts:
Skipped paths: 1
asked Aug 2 '12 at 9:42
JackalopeZero
1,66031343
 
    
maybe untracked files cause the conflict; it's not very clear, what state/contents of that directory("path", is it the same as "intranet/trunk/PYTHON/<application>"?) you had before and after each operation; and what's your SVN version? –  Dmitry Pavlenko Aug 2 '12 at 9:59
    
If you think this is definitely a bug, write to users@subversion.apache.org or #svn channel at FreeNode – Dmitry Pavlenko Aug 2 '12 at 10:00
    
if you haven't update anything in the working copy, normally it won't behave like that. Just to make sure, are you updating the whole working copy to different rev, or just part of it? If it is the former case, it seems to me that's a bug in svn instead. –  Adrian Shum Aug 2 '12 at 10:02
    
Im using subversion-1.7.5-1.fc17.i686. It is the exact same path, Im literally just trying to get a new revision. Whatever I do it will not seem to just download the latest copy. Im trying to update the whole working copy.–  JackalopeZero Aug 2 '12 at 10:05 
1  
The second time it complains about another conflicting node. Maybe you should resolve the conflict with '--depth=infinity' option and something '--accept theirs' in order not to resolve every file manually. But anyway, strange.. Could you post the output of "svn status inm" before and after update? –  Dmitry Pavlenko Aug 2 '12 at 10:33

2 Answers

I think the answer I was looking for here was

svn revert --depth=infinity inm

I dont care about keeping local changes, only to update to a new revision. I have used this command a few times now and it seems to do the trick

EDIT

Upon looking at my errors again I can see that a lot of the files were likely being changed by tests or builds. I should have added them to an ignore file so that their changes were not detected by svn.