subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nico Kadel-Garcia <nka...@gmail.com>
Subject Re: subversion destroys my Working Copy
Date Thu, 17 Jul 2014 12:52:35 GMT
On Thu, Jul 17, 2014 at 6:03 AM, Daniel Migowski <dmigowski@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.

Mime
View raw message