Let's try another tack.
As has been presented, there is an existing hook script that will handle
this situation as long as the locale for the server and all clients are the
same. It seems to me that this ought to cover *all* "private" development.
I say all because for the tiny fraction that may legitimately have different
locales, it's easy enough to dictate the use of one.
For open source projects such as SVN itself, you just don't give committer
privileges to anyone who won't follow the accepted coding conventions for
the project.
With the hook-script facility in place, I think it makes very little sense
to muddy the core libraries with things that can be accomplished with the
scripts. The most powerful and lasting technologies we use are the ones
that don't try to solve too many problems, but are "layer friendly". There
are countless examples of technologies that failed because they try to do
too many things.
So, is there anyone on the list that has an *actual* as opposed to
*theoretical* environment that won't work with the hook script?
----- Original Message -----
From: "Ryan Schmidt" <subversion-2004@ryandesign.com>
To: <users@subversion.tigris.org>
Sent: Thursday, December 23, 2004 7:57 AM
Subject: Re: Renaming files on win32
>
> On 23.12.2004, at 14:18, Philip Martin wrote:
>
> > I'll give it one last go: if you want to help fix this you need to
> > work out what to do. That's not just some vague hand waving about
>
> I'm still quite new to Subversion -- I've only begun reading the manual
> and haven't even tried using the server or client yet, and have never
> looked at the source code -- so forgive me if there's an obvious reason
> why the below won't work.
>
> Someone wrote that "svn mv file FILE" is exactly the same as "svn cp
> file FILE && svn rm file" internally. It might be defined like this
> (giving pseudocode in PHP, sorry):
>
> function svn_mv($from, $to) {
> svn_cp($from, $to);
> svn_rm($from);
> }
> function svn_cp($from, $to) {
> copy $from to $to in the local filesystem;
> make a note that $from needs to be copied to $to in the repository at
> next check-in;
> }
> function svn_rm($file) {
> remove $file from the local filesystem;
> make a note that $file needs to be removed from the repository at next
> check-in;
> }
>
> If we call svn_mv("file", "FILE") it would have this effect:
>
> - copy "file" to "FILE" in the local filesystem
> - make a note that "file" needs to be copied to "FILE" in the
> repository at next check-in
> - remove "file" from the local filesystem
> - make a note that "file" needs to be removed from the repository at
> next check-in
>
> And this assumes a case-sensitive local filesystem, which causes
> problems for Windows (and presumably Mac OS X) clients, and also
> assumes a case-sensitive repository.
>
> The solution for the client side would seem to me to be to make "svn mv
> file FILE" NOT be the exact same thing internally as "svn cp file FILE
> && svn rm file". I assume the reason for making it identical is that 1)
> the svn server doesn't have a mv command and 2) simulating it by
> calling cp and then rm works fine on case-sensitive filesystems like
> those used by Un*x. But Windows (and Mac OS X) surely have functions
> that can correctly rename files on their
> case-insensitive-but-case-preserving filesystems. I would have the "svn
> mv" command use this OS-level facility, and then still send the copy
> and remove commands to the server. Like this:
>
> function svn_mv($from, $to) {
> rename $from to $to in the local filesystem;
> make a note that $from needs to be copied to $to in the repository at
> next check-in;
> make a note that $file needs to be removed from the repository at next
> check-in;
> }
>
> Then for svn_mv("file", "FILE") we have:
>
> - rename "file" to "FILE" in the local filesystem
> - make a note that "file" needs to be copied to "FILE" in the
> repository at next check-in
> - make a note that "file" needs to be removed from the repository at
> next check-in
>
> This would still require a case-sensitive repository, but perhaps
> that's not a problem.
>
> Even better, it would seem, because it would remove the need for a
> case-sensitive repository (it would merely need to preserve case) would
> be to add a command to the server's language so that it can not only
> "A"dd and "D"elete files but also move them. But I have no idea of the
> implications of doing that.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Dec 23 19:24:58 2004