[TSVN] Detection of file changes bug T-SVN 1.1.3

I'd like to report a bug with the detection of whether or not a file
has 'changed' when trying to commit a file. I've had a look at the
other bugs people have reported and I didn't notice this one, so here
goes:

Suppose I have a working directory called MyWorkingDirectory into
which I have Checked-out my Repository into.

MyWorkingDirectory now contains, say, 5 data files: MyFile01,
MyFile02, MyFile03, MyFile04 and MyFile05.

Suppose I make a number of changes to these files and decide to Commit
MyWorkingDirectory as a new Revision (Revision 5, say).

Suppose later I then modify MyFile01, MyFile03 and MyFile04, by
editing them and changing some of data.

Next I decide to recommit the whole MyWorkingDirectory as Revision 6.

But then suppose later still I decide that MyFile03 has been
incorrectly edited and that I want the previous version.

So I select MyFile03 and select Update To Revision ... 5

So far so good.

But when I want to commit MyWorkingDirectory, SVN refuses to
acknowledge this as a change, even though the contents of MyFile03 are
at revision 5 and the rest of the directory is at Revision 6. It gives
the following error:

"No files were changed or added since the last commit. There's nothing
for TortoiseSVN to do here..."

But this is wrong because I want a Revision 7 to reflect the
MyFile03's change from Revision 6 back to Revision 5. Sounds a little
convoluted, I know, but I think this is a genuine request!

Furthermore, with having NOT acknowledged this as a 'change', if I
then click Update, it overwrites the current version of MyFile03
(Revision 5) with the Updated version of MyFile03 (Revision 6) WITHOUT
flagging a Conflict of any sort.

The only way around this I have found is to do a meaningless edit of
MyFile03 (eg open - press <-SPACE->, then press <-DEL-> etc), whereby
SVN will finally acknowledge the change so that when I do an Update it
acknowledges a Conflict. Now I can select Resolved and commit
MyWorkingDirectory again in the usual way and get the Revision 7 I
wanted.

If this handling of is deliberate, then fair enough, but I think this
must be a bug? Intuitively I think SVN should recognise the
discrepancies in Revision numbers of files and flag this as a change.

Appologies for my rather laborious attempt at defining the bug I've
found, but it's the best way I can explain it, even though it is
probably quite a simple concept! Anyway, hope that helps!

Gareth

FYI (from the about box)

TortoiseSVN 1.1.3, Build 2502, UNICODE
Subversion 1.1.3,
apr 0.9.5
apr-iconv 0.9.5
apr-utils 0.9.5
berkeley db 4.2.52
neon 0.24.7
OpenSSL 0.9.7e 25 Oct 2004
zlib 1.2.2

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Fri Apr 1 15:31:38 2005