Sorry for replying that late...
Lieven Govaerts wrote:
> Gerold J. Wucherpfennig wrote:
> > Hi devs,
> > you know - there is a problem with case-insensivity for Windows svn
> > clients when the svn server is on unix.
> Yep, it's also known as issue 2010:
> > In the KDE repository,
> > for example, there are two files with the same name in the same
> > directory. The only difference is the "case". Subversion should
> > at least have an option to ignore all other files which have a
> > different case (and the same name). That would make it possible
> > to check out the repository for people who only have a broadband
> > internet connection with a windows client. And when those people
> > are at home (with their low speed internet connection) they can
> > update the missing file with the other case-sensitive file name.
> You suggest that the checkout completes with a warning about not being
> able to checkout that file?
> Which of the two files should svn choose?
Simply the first one that is checked out :-)
Only for Windows svn clients:
First there has to be the special option "-i"
- only for "svn co" and "svn up".
For every file that has been checked out in the current working
directory there will be saved a lower case version of the file name
in RAM. Before a new file will be checked out of the svn repository
a lower case version of that file will be compared with every other
lower case file name saved in RAM. If two compared (lower case)
file names match exactly, the file will be obmitted and a warning
will be issued. If the current working directory changes, all lower
case versions of the file names will be purged in RAM i.e. deleted.
Then the whole process starts over again.
> I see your problem, checkout stopping in the middle of a potentially
> large operation is not ideal, but is there a better alternative?
What do you think about my proposal?
> > What do you professionals think about that? Sure the file can be
> > renamed in the KDE repository, but on the other hand it's a
> > general problem...
> If you're supposed to be able to use those files on Windows then there's
> no other choice than to rename that file in the repository.
Yes, that's true. I'm not able to use that file names on windows.
Renaming them on the client side doesn't help either, because those
file names are supposed to be like they are in the svn repository
and the Makefiles use those original names.
But imagine that you don't have write access to the svn repository
and you simply want to check out as many files as you can.
I have a windows workstation with a fast internet connection. So I
want to check out as many files as I can and then copy the files to
a linux workstation. There I have a very slow 44kbps internet connection.
Doing a "svn co" will take hours, that's not acceptable for me.
But doing a "svn up" and only get the last missing file would be great.
> I mean, even
> if you'd put that folder in a .tgz and export it on Windows it would
> still fail, right?
> Maybe a pre-commit hook script that checks for files with the same name
> but different case already existing in the repository
I don't want to change anything in the repository. Just think that
I don't have commit access and that I don't want to pose unnecessary
restrictions for the Linux developers...
> - or at least for
> the parts that are useful on windows - could help?
Simply renaming that file will help, of course. But imagine you want
to check out Linux software and the Linux developers don't care
about case-insensivity... that will be a problem for svn clients for
I hope that you agree that my proposed changes would be useful for
the Windows SVN client.
The big (for me big) problem is that I don't know the subversion
sources at all and I have just downloaded and had a quick look into
them. Can you give me some pieces of information about what has to
be changed to implement my proposal?
"Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Fri Apr 6 01:16:59 2007