Will Wilson wrote:
> It's a reasonable point, although I'd very much like it if there was
> some dialog to the effect of "You are about to shoot yourself in the
> foot. Are you sure this is what you want do?". Basically, if they really
> want to do it, by all means let them, just make sure that you give them
> fair warning first.
>
> Additionally, a lot of the artists I work with tend to operate on a file
> basis & not a directory basis when doing commits - thus you have a
> recipe for disaster (as I've found to my cost).
But automatically recover from this would just help them do something
that's not really the way Subversion works. You know Subversion is
folder based, not really file based. So by helping them deal with a
wrong habit, we just try to cover that. I'd rather not do that but
encourage them to change their habits to something that works much
better and more reliable.
>> Also, you have to understand here that there's always some edge cases
>> where TSVN can't fix this problem. That's why you should install a
> pre-
>> commit hook script to not let such things get committed in the first
>> place.
>> http://svn.collab.net/repos/svn/trunk/contrib/hook-scripts/case-
>> insensitive.py
>
> Very true, thanks for the link also; it's a useful last line of defence.
> However, it'd be preferable to repair the issue up front as I'd imagine
> that it's far more useful to most people to fix the problem before the
> commit proceeds. Even with problematic edge cases I think it's still an
> issue worthy of an automated (but informative) WC fix where possible.
>
> What are the edge cases by the way?
Ever used the windows search window? You can select there files from
different directories and even different working copies. In those cases,
Subversion sometimes seems to work ok, but later you then discover that
something still went wrong. TSVN covers most of these situations. But I
think there are still some cases where it just doesn't work (at least
you'll get an error right away, so no danger to your data).
With that search window, we can't just automatically detect and/or
correct the file cases, because those files could come from different
fodlers or working copies. If we would check every file for case
changes, we could basically spend hours until we got them all (imagine a
really big working copy with hundreds of folders, and the search dialog
showing hundreds of files which the user selected all).
Also if a file is currently opened by another application, Subversion
can't determine its status, and that would mean we don't get the data
needed for the case check.
Just two edge cases. The others are far more complicated to describe here.
> If the conversion were only to occur during the add file process then
> surely this shouldn't be too much of an issue? I agree that doing it to
We can't just do it for adding files. The commit dialog would have to do
the same too.
> files already in the repository is only asking for trouble. What were
> the other two edge cases?
See above for two easy ones.
Also, you should be aware that not all languages can convert uppercase
to lowercase and back again without loosing data. A simple example for
german:
straße (street)
converted to uppercase will become
STRASSE
converted back to lowercase
strasse
See the difference? The problem here is that there just is no uppercase
double-s letter (ß).
That's one of those cases where there simply is no way of fixing it.
And I don't like features that only work some times and not all the
times. Because that's like a firealarm that only works on sundays but
people not knowing that. They then rely on the firealarm to work, but
when a fire starts on monday, they'll get burned.
> Good luck against Ukraine! I guess you're going to be quiet tonight as
> well then ;)
The way this day has been going so far, we'll be losing big time. But
maybe my luck will change...
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Mon Jun 26 18:32:27 2006