Arnette, Bill wrote:
> I am trying to reorganize my repository because I forgot to create the
> trunk/branches/tags layout when I first set it up. So I am creating a
> 'trunk' subdir under my current project root and 'svn mv'-ing everything
> into the 'trunk' directory. Many of the moves seem to work fine, but
> every now and again I get the following:
>
> C:\Visual Studio Projects\Products\Application
> >svn mv Test trunk
> svn: Working copy 'trunk\Test\GraphTester\GraphTester' is
> missing or not
> locked
>
> ...and the copy in the 'trunk\Test\GraphTester\GraphTest' is
> incomplete.
>
> Note that error occurs several directories down during the recursive
> move.
>
> Any ideas why this is happening?
I've encountered that myself and I attribute it to some 'lazy copying'
behaviour in Windows / the Windows file system.
Once you start deleting or moving around larger chunks of data
the system will respond fairly quickly with 'Hey, I am done'.
However, at that point of time some files neither vanished
at the origin nor re-appeared at the destination. This happens
especially with more than a few hundred files per directory, when
there is another 'big' copy process, or when there is some other
heavy work on the filesystem in the background. And one gets a nice
snapshot of the real situation when explorer crashes shortly after
reporting success but before the move actually happened... *sigh*
I'd guess the svn client assumes that a file was indeed moved
after the system call returned, tries to continue its svn
related business but fails as the moved file is not yet there.
I think there is no real solution except to quiet down the system
before starting larger transactions, to avoid large directories
(where 'large' starts already at a 'few hundred files'), or
operate on non-Windows file servers 'natively', like ssh'ing
to some Sun box hosting Windows shares via samba and do the
'svn mv' there [but that's rarely an option if your working
copies are on a local drive].
I find this quite annoying to say the least and I actually wonder
why I seem to be the only one at my place bumping regularly into
this 'feature'. But maybe if one grows up on NTFS one gets used
to not to do certain things and if one grows up on *nix one tends
to develop a workflow relying on reliable file operations...
Urm, I just had a look at 'MoveFileEx' documentation. It mentions
a parameter 'MOVEFILE_WRITE_THROUGH': "The function does not return
until the file has actually been moved on the disk". This is not
the default value, so if the svn client does not use this parameter
explicitly it pretty much looks like it would get asyncronous
behaviour - which fit pretty well with the symptoms, doesn't it?
Andre'
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Sep 7 06:56:28 2005