On Thu, Jul 17, 2014 at 6:03 AM, Daniel Migowski <dmigow...@ikoffice.de> wrote: > Hello, > > I have to say sorry for the noise. You were right, after retrying to cleanup > my old copies of the working copy it occurred to me that subversion really > can clean things up. The problem was that during my initial tests I didn't > realize that Eclipse still held the lock when the editor was already closed. > > Sorry for that. > > Regards, > Daniel Migowski
Glad you found the issue and resolved it. My personal approach is "don't use svn:keywords", along with "don't use svn:eol" The erratic and inconsistent contents of a working copy based on various local settings, such as the change author or URL of the upstream repo, and the extra overhead of "I've committed the file and the contents will therefore be altered by the commit itself" for revision based keywords are just begging for this kind of problem to occur again and again and again. The consequence of the casual legibility of such keywords is that you have to spend resources managing keywords, disabling them, avoiding their accidental use in source code that would have its checksums and timestamps altered by checkins, etc. It gets very expensive at odd times, as you just noted. It's frequent use is one of the consequences of the evolution of Subversion from CVS, and it's one that I've found more effective to simply reject and avoid altogether.