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
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
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!
FYI (from the about box)
TortoiseSVN 1.1.3, Build 2502, UNICODE
berkeley db 4.2.52
OpenSSL 0.9.7e 25 Oct 2004
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Fri Apr 1 15:31:38 2005