Brian Frisch wrote:
>> It hasn't - at least I can't reproduce this here at all. I always get
>> the file listed in the commit dialog.
>> Are you sure the file really is modified? Is the file accessible (i.e.
>> no other app has the file open, not even a virus scanner for a short
> I'm sure the file really is modified. This is also backed up by the fact
> that the file is listed when I try to commit the directory which holds
> the file. The file is also accessible.
> The problem again:
> One file has modifications, but when we right click the file, it isn't
> listed in the commit dialog. If we on the other hand try to right click
> the directory which holds the file, it is listed.
> We've tried to study this problem further, and have come up with a
> couple of interesting observations.
> First of all, let me try to describe our environment as detailed as
> We're 4 developers (1,2,3,4), and we're all working on our own separate
> working copy located on a network share (Windows 2000 server) i.e.
> Local machines:
> 1,2,3) A Windows Vista machine, logged in as themselves on a domain
> account without administrator rights on the network, but as local
> administrators. They're all using Tortoise 1.6.2, but experienced the
> problem during 1.6.1 as well.
> 4) A Windows XP machine, logged in as himself on his domain account, but
> accesses the share as domain administrator. He's running Tortoise 1.6.1.
> 1,2,3 are the ones with the problem. 4 doesn't have the problem.
> 1 has tried to copy his working copy from the network share onto his
> local machine, and was successful with committing single files.
> We've also discovered a small workaround:
> Instead of just right clicking a single file, we mark one additional
> file (it doesn't matter whether or not the file has modifications), and
> the file we want to commit, is listed in the commit dialog. This lets me
> to believe that the problem occurs in some kind of comparing method when
> only selecting one modified file.
> On a final note: It seems to be not only when performing commits. We've
> also had the problem when trying to revert single files.
> I don't know if it's a bug in Tortoise only triggered by our unique
> setup, or what it is, but I felt like I owed it to you to report a
> detailed description of the problem.
From your description, it seems that the svn lib can't access the files
with full rights and therefore fails to even find out whether a path
refers to a file or a folder. It then assumes a folder (not sure how the
apr lib determines this, but usually such cross-platform libs try to
open a path with certain flags, and if that fails that means it's a
folder since a folder can't be opened with those file flags).
And of course, you shouldn't put your working copies on a network share.
They're working copies and should be kept local.
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-05-12 18:43:16 CEST