On 22/07/2010 14:08, s...@stsp.name wrote:
On Thu, Jul 22, 2010 at 10:58:44PM +1000, dave b wrote:
Can we at least agree that the current state is suboptimal ?
Sure, but it's the state of windows that is suboptimal.
There simply isn't anything we can reasonably do about it.
Stefan
What if svn.exe (or TortoiseSVN) could issue a warning that the checked
out copy did not represent the repository? Then at least the user would
know about it and could change their repository.
Something like:
"svn.exe: Foo.txt obstructed by foo.txt. Skipping Foo.txt".
At the moment the checkout/update code will not recognise that the file
being added is overwriting a different file from the same checkout.
I'd like to add that this situation doesn't just arise with
cross-platform development. You don't need Linux to create a repository
that won't check out correctly on Windows. A couple of weeks ago a new
user at work decided to standardise the capitalisation of some files,
and did so by renaming the file in the wc, then Adding the file using
TortoiseSVN, then committing.
After that, every checkout or update of that directory would cause there
to be a file with one of the two names, and the contents of the other
file. On a 'status' the situation would show up as a local modification
of the file in the wc, and the other file as Missing.
Even knowing about these problems it took me a little while to realise
what had happened. I suspect that it doesn't matter that my svn server
is linux: I'm sure that the broken situation could have been achieved on
a Windows server with a Windows client.
I'm with everybody else that it doesn't make sense for svn to try to
make it 'work', even cygwin doesn't try to gloss over this issue.
