You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Johan Corveleyn <jc...@gmail.com> on 2011/03/20 21:32:46 UTC
Case-only renames on Windows (issue #3702)
Hi,
I'm looking at issue #3702 ("svn ren TODO todo" not work on windows).
Although this is marked as "1.7-consider", I'd really like this to be
fixed before release, since this is pretty important for me and my
user base. So I'd like to take a stab, but being relatively
inexperienced, I'd like some help ... OTOH, if someone more
experienced can fix this easily, that would be fine too :-).
As explained by Bert in
http://subversion.tigris.org/issues/show_bug.cgi?id=3702#desc6
the remaining issue here is that the command line client normalizes
all paths to their on-disk casing, before passing the paths to the
client layer. Or, following the code:
svn/move_cmd.c#svn_cl__move:
-> svn/util.c#svn_cl__args_to_target_array_print_reserved
-> libsvn_client/cmdline.c#svn_client_args_to_target_array
-> libsvn_subr/opt.c#svn_opt__arg_canonicalize_path
-> apr_filepath_merge(... APR_FILEPATH_TRUENAME ...)
^^^ normalizes case, as indicated by flag ^^^
...
-> pick dst_path of the list of targets
...
-> call libsvn_client/copy.c#svn_client_move6
So: all the target paths of the command are normalized first, and only
after that the dst_path is taken as the last target. By then it's
already transformed to on-disk-casing. I don't really know how to go
about this.
Some thoughts:
- There is only a problem if the dst_path gets case-normalized to one
of the source paths. Otherwise, the case-normalization really does
need to happen.
- Maybe: let it be case-normalized like it is now, together with
everything else, but check afterwards if it's now identical to one of
the source paths. If so, transform back to the original case? Or throw
it again through a canonicalization routine, but without changing
case?
- Since svn_cl__args_to_target_array_print_reserved and lower are
blissfully unaware about what the targets are for (source or dest),
the only place to start the "alternative path" for handling dst_path
would be move_cmd.c#svn_cl__move itself.
- Other useful things happen inside svn_client_args_to_target_array
and svn_opt__arg_canonicalize_path (and in apr_filepath_merge modulo
the APR_FILEPATH_TRUENAME flag), besides the case-normalization. Those
other things probably also need to be done to dst_path, even if it's
not case-normalized. Is there already some code for that?
Any input is appreciated.
How do other svn clients handle this (or will handle this)?
Cheers,
--
Johan
Re: Case-only renames on Windows (issue #3702)
Posted by John Beranek <jo...@redux.org.uk>.
On 25/03/11 10:09, Bolstridge, Andrew wrote:
>
>> -----Original Message----- From: Branko Čibej [mailto:brane@xbc.nu]
>> On Behalf Of Branko Cibej Sent: 24 March 2011 15:32 To:
>> dev@subversion.apache.org Subject: Re: Case-only renames on Windows
>> (issue #3702)
>>
> [snip]
>> In short, things aren't /that/ tricky as far as renames go. They're
>> a lot trickier during update and commit, if the editor hits a local
>> file that has the wrong case on-disk, but is otherwise versioned
>> (I've known brain-dead tools to case-only rename the files they'd
>> worked on).
>>
>> -- Brane
>>
>
> Of course, the best approach would just to make the entire system
> case-insensitive and cater to the lowest common denominator (after
> all, the http transport should be case-insensitive too, I get to the
> same place typing in www.apache.com or www.APACHE.com, but not when
> it comes to the svn repo url).
You may need to explain why people can't put copies of Linux 2.4 kernels
in the system then:
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.4.37.y.git;a=blob;f=net/ipv4/netfilter/ipt_tos.c
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.4.37.y.git;a=blob;f=net/ipv4/netfilter/ipt_TOS.c
Cheers,
John.
--
John Beranek To generalise is to be an idiot.
http://redux.org.uk/ -- William Blake
RE: Case-only renames on Windows (issue #3702)
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Branko Čibej [mailto:brane@xbc.nu] On Behalf Of Branko Cibej
> Sent: vrijdag 25 maart 2011 11:50
> To: Bolstridge, Andrew
> Cc: dev@subversion.apache.org
> Subject: Re: Case-only renames on Windows (issue #3702)
>
> On 25.03.2011 11:09, Bolstridge, Andrew wrote:
> > (after all, the http transport should be case-insensitive too, I get
> > to the same place typing in www.apache.com or www.APACHE.com, but
> not
> > when it comes to the svn repo url).
>
> Oops. Host names are are case-insensitive by definition. Paths in URLs
> are not.
Since Subversion 1.6.0 we normalize all schema and hostnames in urls to lower case. (Urls stored in working copies are automatically converted on upgrading to 1.6.x).
The rest of the url is kept as-is.
In Subversion 1.7 we extended this normalization a bit further to always use the same character escaping, so http://host/path and http://host/p%61th are the same url in 1.7, but not in 1.6.
Only the first format is canonical, so you get an error if you pass the second form to an internal API. Clients can use svn_uri_canonicalize() to get the canonical format of a user provided url.
(Older clients are expected to use the now deprecated svn_path_canonicalize())
Bert
Re: Case-only renames on Windows (issue #3702)
Posted by Branko Čibej <br...@e-reka.si>.
On 25.03.2011 11:09, Bolstridge, Andrew wrote:
> (after all, the http transport should be case-insensitive too, I get
> to the same place typing in www.apache.com or www.APACHE.com, but not
> when it comes to the svn repo url).
Oops. Host names are are case-insensitive by definition. Paths in URLs
are not.
-- Brane
RE: Case-only renames on Windows (issue #3702)
Posted by "Bolstridge, Andrew" <an...@intergraph.com>.
> -----Original Message-----
> From: Branko Čibej [mailto:brane@xbc.nu] On Behalf Of Branko Cibej
> Sent: 24 March 2011 15:32
> To: dev@subversion.apache.org
> Subject: Re: Case-only renames on Windows (issue #3702)
>
[snip]
> In short, things aren't /that/ tricky as far as renames go. They're a lot trickier
> during update and commit, if the editor hits a local file that has the wrong
> case on-disk, but is otherwise versioned (I've known brain-dead tools to
> case-only rename the files they'd worked on).
>
> -- Brane
>
Now you've reminded me of something, those brain-dead tools that rename files you have under svn, and when you come to commit them, they get ignored because the system think's they're new files. TortoiseSVN has some special-case handling for these, try to commit one of them and Tortoise will pop up a messagebox asking if you want to rename the case and retry the operation (and gives you a menu option to rename files directly).
http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-rename.html
Of course, the best approach would just to make the entire system case-insensitive and cater to the lowest common denominator (after all, the http transport should be case-insensitive too, I get to the same place typing in www.apache.com or www.APACHE.com, but not when it comes to the svn repo url).
Re: Case-only renames on Windows (issue #3702)
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Johan Corveleyn wrote on Thu, Apr 14, 2011 at 23:49:16 +0200:
> On Tue, Apr 12, 2011 at 11:14 PM, Johan Corveleyn <jc...@gmail.com> wrote:
> > On Fri, Mar 25, 2011 at 2:21 PM, Johan Corveleyn <jc...@gmail.com> wrote:
> >> On Sun, Mar 20, 2011 at 9:32 PM, Johan Corveleyn <jc...@gmail.com> wrote:
> >>> Some thoughts:
> >>>
> >>> - There is only a problem if the dst_path gets case-normalized to one
> >>> of the source paths. Otherwise, the case-normalization really does
> >>> need to happen.
> >>
> >> Hm, this thought may be incorrect (or at least "unexpected" for
> >> windows users). In fact, if we look at how the native "move" behaves,
> >> it never case-normalizes the target path:
> >>
> >> [[[
> >> C:\Temp>dir /B test
> >> TODO
> >>
> >> C:\Temp>echo anothertest > bla
> >>
> >> C:\Temp>move bla test\toDO
> >> Overwrite C:\Temp\test\toDO? (Yes/No/All): y
> >> 1 file(s) moved.
> >>
> >> C:\Temp>dir /B test
> >> toDO
> >>
> >> C:\Temp>type test\todo
> >> anothertest
> >> ]]]
> >>
> >> So it seems that, if we want "svn mv" to behave more like "move" on
> >> Windows, the target path should never be normalized to the on-disk
> >> casing. Just use it as is ...
> >
> > Finally getting around to this again ... the above is still an open
> > question for specifying the desired behavior of "svn move" on Win32
> > ... If there is a file A on disk, what should "svn move B a" do?
> >
> > In theory it could generate a replace of A by a ("copied from" B).
> > That would be consistent with behavior of Windows' "move" command,
> > after confirming the overwrite.
> >
> > But, lacking the "confirm-for-overwrite", I guess the behavior most
> > consistent with existing svn functionality would be to refuse this
> > move in the same way as "svn move B A" is refused. Currently, this is
> > with the (slightly not-to-the-point) error message: "svn: E155007:
> > Path 'C:\temp\bla\A' is not a directory".
> >
> > Would that be ok?
>
> I think this would be ok: just refuse a move that overwrites another
> local file (need to rm it first).
>
> Now, I just realized that case-only renames (or renames in general)
> only come into play when there are exactly 2 "targets" of the move
> command: the source and the destination (ok, I'm a bit slow, I know
> :-)).
>
> So, for fixing issue #3702 (case-only renames on Windows), if we take
> into account the rest that's been discussed in this thread, we only
> need to do something special:
> - If there are exactly 2 targets
> - If those targets are paths, rather than uris.
> - If normalized dst_path == normalized src_path
>
> In that case I think we should either:
>
> 1) Normalize the original dst_path again, but this time without the
> APR_FILEPATH_TRUENAME flag to apr_filepath_merge, so it isn't
> converted to on-disk-representation.
>
Call me a pedant, but:
Does APR guarantee that it will *not* canonicalize-to-truename if
APR_FILEPATH_TRUENAME is not passed?
That does not follow logically from "APR will canonicalize-to-truename
if APR_FILEPATH_TRUENAME is passed".
> or
>
> 2) Just use the original dst_path as it was passed to the client, un-normalized.
>
>
> I have no idea if it should be 1) (other important normalization-stuff
> going on besides converting it to the on-disk-representation, that
> should still be performed in this case) or 2) ("if the user tells us
> to use this particular representation of the path, let's use it").
>
> Option 2) would of course be much easier. For option 1) code needs to
> be written/copy-pasted/refactored to do all the normalization stuff,
> except passing the flag to apr_filepath_merge.
Re: Case-only renames on Windows (issue #3702)
Posted by Johan Corveleyn <jc...@gmail.com>.
On Tue, Apr 12, 2011 at 11:14 PM, Johan Corveleyn <jc...@gmail.com> wrote:
> On Fri, Mar 25, 2011 at 2:21 PM, Johan Corveleyn <jc...@gmail.com> wrote:
>> On Sun, Mar 20, 2011 at 9:32 PM, Johan Corveleyn <jc...@gmail.com> wrote:
>>> Some thoughts:
>>>
>>> - There is only a problem if the dst_path gets case-normalized to one
>>> of the source paths. Otherwise, the case-normalization really does
>>> need to happen.
>>
>> Hm, this thought may be incorrect (or at least "unexpected" for
>> windows users). In fact, if we look at how the native "move" behaves,
>> it never case-normalizes the target path:
>>
>> [[[
>> C:\Temp>dir /B test
>> TODO
>>
>> C:\Temp>echo anothertest > bla
>>
>> C:\Temp>move bla test\toDO
>> Overwrite C:\Temp\test\toDO? (Yes/No/All): y
>> 1 file(s) moved.
>>
>> C:\Temp>dir /B test
>> toDO
>>
>> C:\Temp>type test\todo
>> anothertest
>> ]]]
>>
>> So it seems that, if we want "svn mv" to behave more like "move" on
>> Windows, the target path should never be normalized to the on-disk
>> casing. Just use it as is ...
>
> Finally getting around to this again ... the above is still an open
> question for specifying the desired behavior of "svn move" on Win32
> ... If there is a file A on disk, what should "svn move B a" do?
>
> In theory it could generate a replace of A by a ("copied from" B).
> That would be consistent with behavior of Windows' "move" command,
> after confirming the overwrite.
>
> But, lacking the "confirm-for-overwrite", I guess the behavior most
> consistent with existing svn functionality would be to refuse this
> move in the same way as "svn move B A" is refused. Currently, this is
> with the (slightly not-to-the-point) error message: "svn: E155007:
> Path 'C:\temp\bla\A' is not a directory".
>
> Would that be ok?
I think this would be ok: just refuse a move that overwrites another
local file (need to rm it first).
Now, I just realized that case-only renames (or renames in general)
only come into play when there are exactly 2 "targets" of the move
command: the source and the destination (ok, I'm a bit slow, I know
:-)).
So, for fixing issue #3702 (case-only renames on Windows), if we take
into account the rest that's been discussed in this thread, we only
need to do something special:
- If there are exactly 2 targets
- If those targets are paths, rather than uris.
- If normalized dst_path == normalized src_path
In that case I think we should either:
1) Normalize the original dst_path again, but this time without the
APR_FILEPATH_TRUENAME flag to apr_filepath_merge, so it isn't
converted to on-disk-representation.
or
2) Just use the original dst_path as it was passed to the client, un-normalized.
I have no idea if it should be 1) (other important normalization-stuff
going on besides converting it to the on-disk-representation, that
should still be performed in this case) or 2) ("if the user tells us
to use this particular representation of the path, let's use it").
Option 2) would of course be much easier. For option 1) code needs to
be written/copy-pasted/refactored to do all the normalization stuff,
except passing the flag to apr_filepath_merge.
Thoughts?
Cheers,
--
Johan
Re: Case-only renames on Windows (issue #3702)
Posted by Johan Corveleyn <jc...@gmail.com>.
On Fri, Mar 25, 2011 at 2:21 PM, Johan Corveleyn <jc...@gmail.com> wrote:
> On Sun, Mar 20, 2011 at 9:32 PM, Johan Corveleyn <jc...@gmail.com> wrote:
>> Some thoughts:
>>
>> - There is only a problem if the dst_path gets case-normalized to one
>> of the source paths. Otherwise, the case-normalization really does
>> need to happen.
>
> Hm, this thought may be incorrect (or at least "unexpected" for
> windows users). In fact, if we look at how the native "move" behaves,
> it never case-normalizes the target path:
>
> [[[
> C:\Temp>dir /B test
> TODO
>
> C:\Temp>echo anothertest > bla
>
> C:\Temp>move bla test\toDO
> Overwrite C:\Temp\test\toDO? (Yes/No/All): y
> 1 file(s) moved.
>
> C:\Temp>dir /B test
> toDO
>
> C:\Temp>type test\todo
> anothertest
> ]]]
>
> So it seems that, if we want "svn mv" to behave more like "move" on
> Windows, the target path should never be normalized to the on-disk
> casing. Just use it as is ...
Finally getting around to this again ... the above is still an open
question for specifying the desired behavior of "svn move" on Win32
... If there is a file A on disk, what should "svn move B a" do?
In theory it could generate a replace of A by a ("copied from" B).
That would be consistent with behavior of Windows' "move" command,
after confirming the overwrite.
But, lacking the "confirm-for-overwrite", I guess the behavior most
consistent with existing svn functionality would be to refuse this
move in the same way as "svn move B A" is refused. Currently, this is
with the (slightly not-to-the-point) error message: "svn: E155007:
Path 'C:\temp\bla\A' is not a directory".
Would that be ok?
Cheers,
--
Johan
Re: Case-only renames on Windows (issue #3702)
Posted by Johan Corveleyn <jc...@gmail.com>.
On Sun, Mar 20, 2011 at 9:32 PM, Johan Corveleyn <jc...@gmail.com> wrote:
> Some thoughts:
>
> - There is only a problem if the dst_path gets case-normalized to one
> of the source paths. Otherwise, the case-normalization really does
> need to happen.
Hm, this thought may be incorrect (or at least "unexpected" for
windows users). In fact, if we look at how the native "move" behaves,
it never case-normalizes the target path:
[[[
C:\Temp>dir /B test
TODO
C:\Temp>echo anothertest > bla
C:\Temp>move bla test\toDO
Overwrite C:\Temp\test\toDO? (Yes/No/All): y
1 file(s) moved.
C:\Temp>dir /B test
toDO
C:\Temp>type test\todo
anothertest
]]]
So it seems that, if we want "svn mv" to behave more like "move" on
Windows, the target path should never be normalized to the on-disk
casing. Just use it as is ...
Cheers,
--
Johan
Re: Case-only renames on Windows (issue #3702)
Posted by Johan Corveleyn <jc...@gmail.com>.
On Fri, Mar 25, 2011 at 1:43 PM, Philip Martin
<ph...@wandisco.com> wrote:
> Johan Corveleyn <jc...@gmail.com> writes:
>
>> C:\Temp\test>dir /B
>> ToDo
>>
>> C:\Temp\test>move todo todo
>>
>> C:\Temp\test>dir /B
>> todo
>
> So "svn mv todo todo" will be a case-only rename, I guess that's OK if
> it is what users expect.
>
> What if the file is already lower-case "todo"? Subversion is happy to
> do
>
> svn rm todo
> svn cp todo@base todo
>
> to generate a replace on commit. Should "svn mv todo todo" generate a
> replace when the file is already "todo"?
Good question. I'm not sure.
There are two other options that I can think of (let's call your
suggestion option 1)):
2) svn could just ignore the no-op move, and do nothing (no warning,
no error, nothing).
3) svn could error out, like it does now, with "Cannot move path
'XXX/todo' into itself"
I think 2) would be more "the Windows way", so if we are aiming for
platform-fidelity here, that would be my choice.
Again, looking at the native "move" command on Windows, we can see
that "move todo todo" acts as if it has done a move, but really didn't
do anything, not even "touch" the file or the parent dir. OTOH, if we
do a real case-only rename, "move todo TODO", the timestamp of the
parent dir is updated (i.e., it really has changed). See below.
[[[
C:\Temp\test>echo test > todo
C:\Temp\test>dir
Volume in drive C has no label.
Volume Serial Number is 98BA-E619
Directory of C:\Temp\test
25/03/2011 13:57 <DIR> .
25/03/2011 13:57 <DIR> ..
25/03/2011 13:57 7 todo
1 File(s) 7 bytes
2 Dir(s) 2.945.830.912 bytes free
C:\Temp\test>time /t
13:59
C:\Temp\test>move todo todo
1 file(s) moved.
C:\Temp\test>dir
Volume in drive C has no label.
Volume Serial Number is 98BA-E619
Directory of C:\Temp\test
25/03/2011 13:57 <DIR> .
25/03/2011 13:57 <DIR> ..
25/03/2011 13:57 7 todo
1 File(s) 7 bytes
2 Dir(s) 2.945.384.448 bytes free
C:\Temp\test>move todo TODO
1 file(s) moved.
C:\Temp\test>dir
Volume in drive C has no label.
Volume Serial Number is 98BA-E619
Directory of C:\Temp\test
25/03/2011 14:00 <DIR> .
25/03/2011 14:00 <DIR> ..
25/03/2011 13:57 7 TODO
1 File(s) 7 bytes
2 Dir(s) 2.945.363.968 bytes free
]]]
Cheers,
--
Johan
Re: Case-only renames on Windows (issue #3702)
Posted by Philip Martin <ph...@wandisco.com>.
Johan Corveleyn <jc...@gmail.com> writes:
> C:\Temp\test>dir /B
> ToDo
>
> C:\Temp\test>move todo todo
>
> C:\Temp\test>dir /B
> todo
So "svn mv todo todo" will be a case-only rename, I guess that's OK if
it is what users expect.
What if the file is already lower-case "todo"? Subversion is happy to
do
svn rm todo
svn cp todo@base todo
to generate a replace on commit. Should "svn mv todo todo" generate a
replace when the file is already "todo"?
--
Philip
Re: Case-only renames on Windows (issue #3702)
Posted by Johan Corveleyn <jc...@gmail.com>.
2011/3/24 Branko Čibej <br...@e-reka.si>:
> On 24.03.2011 15:22, Philip Martin wrote:
>> Johan Corveleyn <jc...@gmail.com> writes:
>>
>>> I'm looking at issue #3702 ("svn ren TODO todo" not work on windows).
>> It's a bit tricky :) Consider a mixed-case node "Foo". It's seems
>> obvious that
>>
>> svn mv Foo foo
>>
>> is a case-only rename. But what about
>>
>> svn mv FOO foo
>>
>> or
>> svn mv foo foo
>>
>> It's possible to do a case-only rename whenever the destination doesn't
>> match the disk, but should we require the source to match?
>
> Clearly not ... case-only rename on a case-inseneitive file-system
> assumes that the file-system is case-insensitive. :)
>
>> The node "Foo" might contain a child "Zig", is
>>
>> svn mv Foo/Zig foo/Zig
>
> That's a no-op. You've not renamed Zig.
>
>> a case-only rename? If that is a case-only rename what about
>>
>> svn mv Foo/Zig foo/zig
>
> That's a case-only rename of Foo/Zig to Foo/zig.
>
>> is that two renames? Suppose there are two children "Zig" and "Zag",
>> if
>>
>> svn mv Foo/Zig foo/Zig
>>
>> is a case-only rename it would affect "Foo/Zag".
>
> You're really piling it on here, starting from wrong premises. :)
> A rename affects the last component of a path, nothing more. I've never
> heard of a system when you can case-only rename a directory in the
> middle of a path.
>
> In short, things aren't /that/ tricky as far as renames go. They're a
> lot trickier during update and commit, if the editor hits a local file
> that has the wrong case on-disk, but is otherwise versioned (I've known
> brain-dead tools to case-only rename the files they'd worked on).
Philip, Brane,
Thanks for thinking this through. I hadn't actually thought that far.
I think Brane is right:
- The source path should handled case-insensitively. If it matches
case-insensitively with the source path, that's the path that will be
affected by the move. The case of the target path is then taken "as
is" for the rename/move.
- Rename only affects the last component of a path
I think this is the correct behavior on Windows, because that's the
way the native "move" command behaves:
[[[
C:\Temp\test>echo test > TODO
C:\Temp\test>dir /B
TODO
C:\Temp\test>move toDo ToDo
C:\Temp\test>dir /B
ToDo
C:\Temp\test>move todo todo
C:\Temp\test>dir /B
todo
C:\Temp\test>cd ..
C:\Temp>move TEST\TOdo tEsT\toDO
C:\Temp>dir /B
test
C:\Temp>dir /B test
toDO
]]]
Cheers,
--
Johan
Re: Case-only renames on Windows (issue #3702)
Posted by Branko Čibej <br...@e-reka.si>.
On 24.03.2011 15:22, Philip Martin wrote:
> Johan Corveleyn <jc...@gmail.com> writes:
>
>> I'm looking at issue #3702 ("svn ren TODO todo" not work on windows).
> It's a bit tricky :) Consider a mixed-case node "Foo". It's seems
> obvious that
>
> svn mv Foo foo
>
> is a case-only rename. But what about
>
> svn mv FOO foo
>
> or
> svn mv foo foo
>
> It's possible to do a case-only rename whenever the destination doesn't
> match the disk, but should we require the source to match?
Clearly not ... case-only rename on a case-inseneitive file-system
assumes that the file-system is case-insensitive. :)
> The node "Foo" might contain a child "Zig", is
>
> svn mv Foo/Zig foo/Zig
That's a no-op. You've not renamed Zig.
> a case-only rename? If that is a case-only rename what about
>
> svn mv Foo/Zig foo/zig
That's a case-only rename of Foo/Zig to Foo/zig.
> is that two renames? Suppose there are two children "Zig" and "Zag",
> if
>
> svn mv Foo/Zig foo/Zig
>
> is a case-only rename it would affect "Foo/Zag".
You're really piling it on here, starting from wrong premises. :)
A rename affects the last component of a path, nothing more. I've never
heard of a system when you can case-only rename a directory in the
middle of a path.
In short, things aren't /that/ tricky as far as renames go. They're a
lot trickier during update and commit, if the editor hits a local file
that has the wrong case on-disk, but is otherwise versioned (I've known
brain-dead tools to case-only rename the files they'd worked on).
-- Brane
Re: Case-only renames on Windows (issue #3702)
Posted by Philip Martin <ph...@wandisco.com>.
Johan Corveleyn <jc...@gmail.com> writes:
> I'm looking at issue #3702 ("svn ren TODO todo" not work on windows).
It's a bit tricky :) Consider a mixed-case node "Foo". It's seems
obvious that
svn mv Foo foo
is a case-only rename. But what about
svn mv FOO foo
or
svn mv foo foo
It's possible to do a case-only rename whenever the destination doesn't
match the disk, but should we require the source to match?
The node "Foo" might contain a child "Zig", is
svn mv Foo/Zig foo/Zig
a case-only rename? If that is a case-only rename what about
svn mv Foo/Zig foo/zig
is that two renames? Suppose there are two children "Zig" and "Zag",
if
svn mv Foo/Zig foo/Zig
is a case-only rename it would affect "Foo/Zag".
A set of rules:
- only the last component can be a case-only rename
- the source must match the "real" case on disk
- the destination must differ from the source
would allow users to do case-only renames, and would have the advantage
that the behaviour would be similar to most case-sensitive filesystems.
I'm not exactly sure how canonicalisation works on Windows, does it
allow us to identify the "real" case on disk? If not then perhaps just
the first and last of the above two rules would be enough?
How about the following: the application does canonicalization on the
two paths, and compares the canonical paths. If the paths match it
passes the original paths into some libsvn_client function that
implements the above rules. That would give all Windows clients an easy
way to get some sort of "standard" behaviour.
--
Philip
Re: Case-only renames on Windows (issue #3702)
Posted by Johan Corveleyn <jc...@gmail.com>.
On Tue, Mar 22, 2011 at 1:08 AM, Hyrum K Wright <hy...@hyrumwright.org> wrote:
> On Sun, Mar 20, 2011 at 3:32 PM, Johan Corveleyn <jc...@gmail.com> wrote:
>> Hi,
>>
>> I'm looking at issue #3702 ("svn ren TODO todo" not work on windows).
>> Although this is marked as "1.7-consider", I'd really like this to be
>> fixed before release, since this is pretty important for me and my
>> user base. So I'd like to take a stab, but being relatively
>> inexperienced, I'd like some help ... OTOH, if someone more
>> experienced can fix this easily, that would be fine too :-).
>
> All 1.7-consider means is "sure, we'd like to have it in there, but we
> aren't going to hold the release for it". It *does not* mean "there
> is no way this is getting into the release." These characterizations
> are of course subjective and fluid, and if it gets fixed before 1.7
> branches, ain't nobody gonna stand in the way of releasing it.
Sure, no problem. It's just that I personally think this is a release
blocker. I wouldn't want to confront my own (windows) users when they
find out this still doesn't work ... "What? They did a complete
rewrite of the working copy system, and we still can't do a case-only
rename? Sjeesh." :-).
Though I certainly realize there are a lot of "even more blocking"
issues than this one right now (and bigger and more difficult too),
and we do want to get 1.7 out the door asap. So I can understand
current focus is on those other important ones ...
Anyway, whatever the "milestone" designation of this issue, I'm
looking at it either way. Not that I can give any guarantee that I'll
get it fixed before release, ... my free time is kind of scarce these
days. But I'm trying :-) ...
--
Johan
Re: Case-only renames on Windows (issue #3702)
Posted by Hyrum K Wright <hy...@hyrumwright.org>.
On Sun, Mar 20, 2011 at 3:32 PM, Johan Corveleyn <jc...@gmail.com> wrote:
> Hi,
>
> I'm looking at issue #3702 ("svn ren TODO todo" not work on windows).
> Although this is marked as "1.7-consider", I'd really like this to be
> fixed before release, since this is pretty important for me and my
> user base. So I'd like to take a stab, but being relatively
> inexperienced, I'd like some help ... OTOH, if someone more
> experienced can fix this easily, that would be fine too :-).
All 1.7-consider means is "sure, we'd like to have it in there, but we
aren't going to hold the release for it". It *does not* mean "there
is no way this is getting into the release." These characterizations
are of course subjective and fluid, and if it gets fixed before 1.7
branches, ain't nobody gonna stand in the way of releasing it.
I've only skimmed the rest of the mail, and have no comments, but
wanted to make sure the 1.7-consider-ness of the issue didn't dampen
your enthusiasm.
-Hyrum
>
> As explained by Bert in
>
> http://subversion.tigris.org/issues/show_bug.cgi?id=3702#desc6
>
> the remaining issue here is that the command line client normalizes
> all paths to their on-disk casing, before passing the paths to the
> client layer. Or, following the code:
>
> svn/move_cmd.c#svn_cl__move:
> -> svn/util.c#svn_cl__args_to_target_array_print_reserved
> -> libsvn_client/cmdline.c#svn_client_args_to_target_array
> -> libsvn_subr/opt.c#svn_opt__arg_canonicalize_path
> -> apr_filepath_merge(... APR_FILEPATH_TRUENAME ...)
> ^^^ normalizes case, as indicated by flag ^^^
> ...
> -> pick dst_path of the list of targets
> ...
> -> call libsvn_client/copy.c#svn_client_move6
>
> So: all the target paths of the command are normalized first, and only
> after that the dst_path is taken as the last target. By then it's
> already transformed to on-disk-casing. I don't really know how to go
> about this.
>
> Some thoughts:
>
> - There is only a problem if the dst_path gets case-normalized to one
> of the source paths. Otherwise, the case-normalization really does
> need to happen.
>
> - Maybe: let it be case-normalized like it is now, together with
> everything else, but check afterwards if it's now identical to one of
> the source paths. If so, transform back to the original case? Or throw
> it again through a canonicalization routine, but without changing
> case?
>
> - Since svn_cl__args_to_target_array_print_reserved and lower are
> blissfully unaware about what the targets are for (source or dest),
> the only place to start the "alternative path" for handling dst_path
> would be move_cmd.c#svn_cl__move itself.
>
> - Other useful things happen inside svn_client_args_to_target_array
> and svn_opt__arg_canonicalize_path (and in apr_filepath_merge modulo
> the APR_FILEPATH_TRUENAME flag), besides the case-normalization. Those
> other things probably also need to be done to dst_path, even if it's
> not case-normalized. Is there already some code for that?
>
> Any input is appreciated.
>
> How do other svn clients handle this (or will handle this)?
>
> Cheers,
> --
> Johan
>