You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Ivan Zhakov <iv...@visualsvn.com> on 2014/04/23 13:28:12 UTC
Re: svn commit: r1589262 - /subversion/trunk/subversion/libsvn_fs_fs/fs.c
On 22 April 2014 23:36, <st...@apache.org> wrote:
> Author: stefan2
> Date: Tue Apr 22 19:36:12 2014
> New Revision: 1589262
>
> URL: http://svn.apache.org/r1589262
> Log:
> Fix a scalability issue with FSFS repositories: The lock mutexes are
> part of the process-wide per-repo shared structs. Using only the
> UUID as identification for the repo is not enough in case a repo gets
> duplicated or the admins don't follow good practice. The result may
> be serializing all commits globally across all repos.
>
> Now, we simply add the normalized repo path to the hash key but keep
> the UUID as well. The latter allows us to detect and handle replaced
> repositories gracefully in some cases.
>
> * subversion/libsvn_fs_fs/fs.c
> (fs_serialized_init): Add FS path to the hash lookup key.
>
> Modified:
> subversion/trunk/subversion/libsvn_fs_fs/fs.c
>
> Modified: subversion/trunk/subversion/libsvn_fs_fs/fs.c
> URL: http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_fs_fs/fs.c?rev=1589262&r1=1589261&r2=1589262&view=diff
> ==============================================================================
> --- subversion/trunk/subversion/libsvn_fs_fs/fs.c (original)
> +++ subversion/trunk/subversion/libsvn_fs_fs/fs.c Tue Apr 22 19:36:12 2014
> @@ -72,19 +72,12 @@ fs_serialized_init(svn_fs_t *fs, apr_poo
> each separate repository opened during the lifetime of the
> svn_fs_initialize pool. It's unlikely that anyone will notice
> the modest expenditure; the alternative is to allocate each structure
> - in a subpool, add a reference-count, and add a serialized deconstructor
> - to the FS vtable. That's more machinery than it's worth.
> -
> - Using the uuid to obtain the lock creates a corner case if a
> - caller uses svn_fs_set_uuid on the repository in a process where
> - other threads might be using the same repository through another
> - FS object. The only real-world consumer of svn_fs_set_uuid is
> - "svnadmin load", so this is a low-priority problem, and we don't
> - know of a better way of associating such data with the
> - repository. */
> + in a subpool, add a reference-count, and add a serialized destructor
> + to the FS vtable. That's more machinery than it's worth. */
>
> SVN_ERR_ASSERT(fs->uuid);
> key = apr_pstrcat(pool, SVN_FSFS_SHARED_USERDATA_PREFIX, fs->uuid,
> + svn_fs__canonicalize_abspath(fs->path, pool),
> SVN_VA_NULL);
Hi Stefan,
I agree that problem is important and should be fixed somehow, but
committed fix is wrong IMHO:
1. svn_fs__canonicalize_abspath is for FS path canonicalization, not
for disk path
2. fs->path is not absolute path, so you may get different keys for
same repository accessed but different path relative path
3. On Windows path names is case insensitive and repository can be
accessed using 'C:\REPO' and 'C:\repo' path names. Converting path to
upper case because Windows performs different normalization like
removing trailing dot and etc. Reimplementing this logic in Subversion
will be very hard.
--
Ivan Zhakov
CTO | VisualSVN | http://www.visualsvn.com
RE: svn commit: r1589262 - /subversion/trunk/subversion/libsvn_fs_fs/fs.c
Posted by Bert Huijben <be...@qqmail.nl>.
Is it a problem to have multiple keys pointing to the same repository?
(I think the answer is no)
The problem Stefan tried to solve is one key pointing to multiple repositories… in this case both source and target of the hotcopy.
The svn_fspath__ -> svn_dirent_ fix is really necessary, but the other points might be nice to fix, but I’m guessing that will be mostly impossible.
The rules on how character folding is handled on Windows are just not reproducible in normal applications. (The case folding table depends on the exact collation used when creating the volume.) Obtaining the true path name from disk (which is the only stable way I can think of) is usually too expensive to use in this caching scenario.
Bert
From: Stefan Fuhrmann [mailto:stefan.fuhrmann@wandisco.com]
Sent: woensdag 23 april 2014 13:58
To: Ivan Zhakov
Cc: Subversion Development; Stefan Fuhrman
Subject: Re: svn commit: r1589262 - /subversion/trunk/subversion/libsvn_fs_fs/fs.c
On Wed, Apr 23, 2014 at 1:28 PM, Ivan Zhakov <ivan@visualsvn.com <ma...@visualsvn.com> > wrote:
On 22 April 2014 23:36, <stefan2@apache.org <ma...@apache.org> > wrote:
> Author: stefan2
> Date: Tue Apr 22 19:36:12 2014
> New Revision: 1589262
>
> URL: http://svn.apache.org/r1589262
> Log:
> Fix a scalability issue with FSFS repositories: The lock mutexes are
> part of the process-wide per-repo shared structs. Using only the
> UUID as identification for the repo is not enough in case a repo gets
> duplicated or the admins don't follow good practice. The result may
> be serializing all commits globally across all repos.
>
> Now, we simply add the normalized repo path to the hash key but keep
> the UUID as well. The latter allows us to detect and handle replaced
> repositories gracefully in some cases.
>
> * subversion/libsvn_fs_fs/fs.c
> (fs_serialized_init): Add FS path to the hash lookup key.
>
> Modified:
> subversion/trunk/subversion/libsvn_fs_fs/fs.c
>
> Modified: subversion/trunk/subversion/libsvn_fs_fs/fs.c
> URL: http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_fs_fs/fs.c?rev=1589262 <http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_fs_fs/fs.c?rev=1589262&r1=1589261&r2=1589262&view=diff> &r1=1589261&r2=1589262&view=diff
> ==============================================================================
> --- subversion/trunk/subversion/libsvn_fs_fs/fs.c (original)
> +++ subversion/trunk/subversion/libsvn_fs_fs/fs.c Tue Apr 22 19:36:12 2014
> @@ -72,19 +72,12 @@ fs_serialized_init(svn_fs_t *fs, apr_poo
> each separate repository opened during the lifetime of the
> svn_fs_initialize pool. It's unlikely that anyone will notice
> the modest expenditure; the alternative is to allocate each structure
> - in a subpool, add a reference-count, and add a serialized deconstructor
> - to the FS vtable. That's more machinery than it's worth.
> -
> - Using the uuid to obtain the lock creates a corner case if a
> - caller uses svn_fs_set_uuid on the repository in a process where
> - other threads might be using the same repository through another
> - FS object. The only real-world consumer of svn_fs_set_uuid is
> - "svnadmin load", so this is a low-priority problem, and we don't
> - know of a better way of associating such data with the
> - repository. */
> + in a subpool, add a reference-count, and add a serialized destructor
> + to the FS vtable. That's more machinery than it's worth. */
>
> SVN_ERR_ASSERT(fs->uuid);
> key = apr_pstrcat(pool, SVN_FSFS_SHARED_USERDATA_PREFIX, fs->uuid,
> + svn_fs__canonicalize_abspath(fs->path, pool),
> SVN_VA_NULL);
Hi Stefan,
I agree that problem is important and should be fixed somehow, but
committed fix is wrong IMHO:
1. svn_fs__canonicalize_abspath is for FS path canonicalization, not
for disk path
2. fs->path is not absolute path, so you may get different keys for
same repository accessed but different path relative path
3. On Windows path names is case insensitive and repository can be
accessed using 'C:\REPO' and 'C:\repo' path names. Converting path to
upper case because Windows performs different normalization like
removing trailing dot and etc. Reimplementing this logic in Subversion
will be very hard.
Alright, do you have a suggestion for how to handle
that problem? Without r1589262, we can't lock the
source *and* target of a hotcopy - which is how I ran
into this issue.
-- Stefan^2.
Re: svn commit: r1589262 - /subversion/trunk/subversion/libsvn_fs_fs/fs.c
Posted by Stefan Fuhrmann <st...@wandisco.com>.
On Tue, Apr 29, 2014 at 1:24 PM, Stefan Fuhrmann <
stefan.fuhrmann@wandisco.com> wrote:
> On Thu, Apr 24, 2014 at 11:55 AM, Philip Martin <
> philip.martin@wandisco.com> wrote:
>
>> Stefan Fuhrmann <st...@wandisco.com> writes:
>>
>> > Since no functionality depended on the change so far, except
>> > for some extra fool-proving during hotcopy, I reverted the change
>> > in r1589518.
>>
>> svnadmin_tests.py 40 started to take advantage of your change and would
>> hang after you reverted it. The problem was
>>
>> svnadmin create repo1
>> svnadmin hotcopy repo1 repo2
>> echo repo1 > repos
>> echo repo2 >> repos
>> svnadmin freeze -F repos true
>>
>
> I'm aware of that problem. It should already be present in 1.8.x.
> But my original patch clearly broke our locking guarantees in
> some not-so-obvious-to-the-user cases, so it had to be reverted.
>
> I've changed the hotcopy UUID to avoid the hang. Could FSFS detect the
>> deadlock and return an error rather than hang?
>>
>
> If we allow for some false negatives, then yes. We could store
> the thread ID alongside the lock and test that before attempting
> to acquire it. This mechanism would need to be FSFS-internal
> only as it is unclear whether we would allow for the unknown
> overhead in all places that use svn_mutex__t.
>
> -- Stefan^2.
>
So, r1591872 adds a very small overhead to all uses of svn_mutex__t
but for that we get optional recursion everywhere.
-- Stefan^2.
Re: svn commit: r1589262 - /subversion/trunk/subversion/libsvn_fs_fs/fs.c
Posted by Stefan Fuhrmann <st...@wandisco.com>.
On Thu, Apr 24, 2014 at 11:55 AM, Philip Martin
<ph...@wandisco.com>wrote:
> Stefan Fuhrmann <st...@wandisco.com> writes:
>
> > Since no functionality depended on the change so far, except
> > for some extra fool-proving during hotcopy, I reverted the change
> > in r1589518.
>
> svnadmin_tests.py 40 started to take advantage of your change and would
> hang after you reverted it. The problem was
>
> svnadmin create repo1
> svnadmin hotcopy repo1 repo2
> echo repo1 > repos
> echo repo2 >> repos
> svnadmin freeze -F repos true
>
I'm aware of that problem. It should already be present in 1.8.x.
But my original patch clearly broke our locking guarantees in
some not-so-obvious-to-the-user cases, so it had to be reverted.
I've changed the hotcopy UUID to avoid the hang. Could FSFS detect the
> deadlock and return an error rather than hang?
>
If we allow for some false negatives, then yes. We could store
the thread ID alongside the lock and test that before attempting
to acquire it. This mechanism would need to be FSFS-internal
only as it is unclear whether we would allow for the unknown
overhead in all places that use svn_mutex__t.
-- Stefan^2.
Re: svn commit: r1589262 - /subversion/trunk/subversion/libsvn_fs_fs/fs.c
Posted by Philip Martin <ph...@wandisco.com>.
Stefan Fuhrmann <st...@wandisco.com> writes:
> Since no functionality depended on the change so far, except
> for some extra fool-proving during hotcopy, I reverted the change
> in r1589518.
svnadmin_tests.py 40 started to take advantage of your change and would
hang after you reverted it. The problem was
svnadmin create repo1
svnadmin hotcopy repo1 repo2
echo repo1 > repos
echo repo2 >> repos
svnadmin freeze -F repos true
I've changed the hotcopy UUID to avoid the hang. Could FSFS detect the
deadlock and return an error rather than hang?
--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
Re: svn commit: r1589262 - /subversion/trunk/subversion/libsvn_fs_fs/fs.c
Posted by Stefan Fuhrmann <st...@wandisco.com>.
On Wed, Apr 23, 2014 at 3:07 PM, Ivan Zhakov <iv...@visualsvn.com> wrote:
> On 23 April 2014 15:57, Stefan Fuhrmann <st...@wandisco.com>
> wrote:
> > On Wed, Apr 23, 2014 at 1:28 PM, Ivan Zhakov <iv...@visualsvn.com> wrote:
> >>
> >> On 22 April 2014 23:36, <st...@apache.org> wrote:
> >> > Author: stefan2
> >> > Date: Tue Apr 22 19:36:12 2014
> >> > New Revision: 1589262
> >> >
> >> > URL: http://svn.apache.org/r1589262
> >> > Log:
> >> > Fix a scalability issue with FSFS repositories: The lock mutexes are
> >> > part of the process-wide per-repo shared structs. Using only the
> >> > UUID as identification for the repo is not enough in case a repo gets
> >> > duplicated or the admins don't follow good practice. The result may
> >> > be serializing all commits globally across all repos.
> >> >
> >> > Now, we simply add the normalized repo path to the hash key but keep
> >> > the UUID as well. The latter allows us to detect and handle replaced
> >> > repositories gracefully in some cases.
> >> >
> >> > * subversion/libsvn_fs_fs/fs.c
> >> > (fs_serialized_init): Add FS path to the hash lookup key.
> >> >
> >> > Modified:
> >> > subversion/trunk/subversion/libsvn_fs_fs/fs.c
> >> >
> >> > Modified: subversion/trunk/subversion/libsvn_fs_fs/fs.c
> >> > URL:
> >> >
> http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_fs_fs/fs.c?rev=1589262&r1=1589261&r2=1589262&view=diff
> >> >
> >> >
> ==============================================================================
> >> > --- subversion/trunk/subversion/libsvn_fs_fs/fs.c (original)
> >> > +++ subversion/trunk/subversion/libsvn_fs_fs/fs.c Tue Apr 22 19:36:12
> >> > 2014
> >> > @@ -72,19 +72,12 @@ fs_serialized_init(svn_fs_t *fs, apr_poo
> >> > each separate repository opened during the lifetime of the
> >> > svn_fs_initialize pool. It's unlikely that anyone will notice
> >> > the modest expenditure; the alternative is to allocate each
> >> > structure
> >> > - in a subpool, add a reference-count, and add a serialized
> >> > deconstructor
> >> > - to the FS vtable. That's more machinery than it's worth.
> >> > -
> >> > - Using the uuid to obtain the lock creates a corner case if a
> >> > - caller uses svn_fs_set_uuid on the repository in a process where
> >> > - other threads might be using the same repository through another
> >> > - FS object. The only real-world consumer of svn_fs_set_uuid is
> >> > - "svnadmin load", so this is a low-priority problem, and we don't
> >> > - know of a better way of associating such data with the
> >> > - repository. */
> >> > + in a subpool, add a reference-count, and add a serialized
> >> > destructor
> >> > + to the FS vtable. That's more machinery than it's worth. */
> >> >
> >> > SVN_ERR_ASSERT(fs->uuid);
> >> > key = apr_pstrcat(pool, SVN_FSFS_SHARED_USERDATA_PREFIX, fs->uuid,
> >> > + svn_fs__canonicalize_abspath(fs->path, pool),
> >> > SVN_VA_NULL);
> >> Hi Stefan,
> >>
> >> I agree that problem is important and should be fixed somehow, but
> >> committed fix is wrong IMHO:
> >> 1. svn_fs__canonicalize_abspath is for FS path canonicalization, not
> >> for disk path
> >> 2. fs->path is not absolute path, so you may get different keys for
> >> same repository accessed but different path relative path
> >> 3. On Windows path names is case insensitive and repository can be
> >> accessed using 'C:\REPO' and 'C:\repo' path names. Converting path to
> >> upper case because Windows performs different normalization like
> >> removing trailing dot and etc. Reimplementing this logic in Subversion
> >> will be very hard.
> >
> >
> > Alright, do you have a suggestion for how to handle
> > that problem? Without r1589262, we can't lock the
> > source *and* target of a hotcopy - which is how I ran
> > into this issue.
> >
> I don't have solution, except adding second 'instance UUID' that's
> updated on hotcopy and repository create.
>
I plan to add instance IDs in 1.10. They are useful in a variety
of scenarios where you want guarantee cache consistency
with externally modified repositories.
But you fix making things worse: before your change locks only
> scalability/performance issue exists, but now same repositories
> accessed with different path will get different shared data and
> transaction list will not be locked correctly.
>
Before the change, there would be a deadlock when a thread
tried to take out the same locks on different repositories that
happen to have the same UUID. This is why r1589518 is not
a simple revert.
I disagree with Bert that problem I describe is not possible in normal
> application: any server using SVNParentPath and svnserve are affected,
> because it uses part of URL as repository name. So users accessing
> http://server/repo and http://server/REPO will access repository with
> different path and get different FS shared data.
>
Since no functionality depended on the change so far, except
for some extra fool-proving during hotcopy, I reverted the change
in r1589518.
1.10 will bring the more reliable instance ID fix.
-- Stefan^2.
Re: svn commit: r1589262 - /subversion/trunk/subversion/libsvn_fs_fs/fs.c
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On 23 April 2014 15:57, Stefan Fuhrmann <st...@wandisco.com> wrote:
> On Wed, Apr 23, 2014 at 1:28 PM, Ivan Zhakov <iv...@visualsvn.com> wrote:
>>
>> On 22 April 2014 23:36, <st...@apache.org> wrote:
>> > Author: stefan2
>> > Date: Tue Apr 22 19:36:12 2014
>> > New Revision: 1589262
>> >
>> > URL: http://svn.apache.org/r1589262
>> > Log:
>> > Fix a scalability issue with FSFS repositories: The lock mutexes are
>> > part of the process-wide per-repo shared structs. Using only the
>> > UUID as identification for the repo is not enough in case a repo gets
>> > duplicated or the admins don't follow good practice. The result may
>> > be serializing all commits globally across all repos.
>> >
>> > Now, we simply add the normalized repo path to the hash key but keep
>> > the UUID as well. The latter allows us to detect and handle replaced
>> > repositories gracefully in some cases.
>> >
>> > * subversion/libsvn_fs_fs/fs.c
>> > (fs_serialized_init): Add FS path to the hash lookup key.
>> >
>> > Modified:
>> > subversion/trunk/subversion/libsvn_fs_fs/fs.c
>> >
>> > Modified: subversion/trunk/subversion/libsvn_fs_fs/fs.c
>> > URL:
>> > http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_fs_fs/fs.c?rev=1589262&r1=1589261&r2=1589262&view=diff
>> >
>> > ==============================================================================
>> > --- subversion/trunk/subversion/libsvn_fs_fs/fs.c (original)
>> > +++ subversion/trunk/subversion/libsvn_fs_fs/fs.c Tue Apr 22 19:36:12
>> > 2014
>> > @@ -72,19 +72,12 @@ fs_serialized_init(svn_fs_t *fs, apr_poo
>> > each separate repository opened during the lifetime of the
>> > svn_fs_initialize pool. It's unlikely that anyone will notice
>> > the modest expenditure; the alternative is to allocate each
>> > structure
>> > - in a subpool, add a reference-count, and add a serialized
>> > deconstructor
>> > - to the FS vtable. That's more machinery than it's worth.
>> > -
>> > - Using the uuid to obtain the lock creates a corner case if a
>> > - caller uses svn_fs_set_uuid on the repository in a process where
>> > - other threads might be using the same repository through another
>> > - FS object. The only real-world consumer of svn_fs_set_uuid is
>> > - "svnadmin load", so this is a low-priority problem, and we don't
>> > - know of a better way of associating such data with the
>> > - repository. */
>> > + in a subpool, add a reference-count, and add a serialized
>> > destructor
>> > + to the FS vtable. That's more machinery than it's worth. */
>> >
>> > SVN_ERR_ASSERT(fs->uuid);
>> > key = apr_pstrcat(pool, SVN_FSFS_SHARED_USERDATA_PREFIX, fs->uuid,
>> > + svn_fs__canonicalize_abspath(fs->path, pool),
>> > SVN_VA_NULL);
>> Hi Stefan,
>>
>> I agree that problem is important and should be fixed somehow, but
>> committed fix is wrong IMHO:
>> 1. svn_fs__canonicalize_abspath is for FS path canonicalization, not
>> for disk path
>> 2. fs->path is not absolute path, so you may get different keys for
>> same repository accessed but different path relative path
>> 3. On Windows path names is case insensitive and repository can be
>> accessed using 'C:\REPO' and 'C:\repo' path names. Converting path to
>> upper case because Windows performs different normalization like
>> removing trailing dot and etc. Reimplementing this logic in Subversion
>> will be very hard.
>
>
> Alright, do you have a suggestion for how to handle
> that problem? Without r1589262, we can't lock the
> source *and* target of a hotcopy - which is how I ran
> into this issue.
>
I don't have solution, except adding second 'instance UUID' that's
updated on hotcopy and repository create.
But you fix making things worse: before your change locks only
scalability/performance issue exists, but now same repositories
accessed with different path will get different shared data and
transaction list will not be locked correctly.
I disagree with Bert that problem I describe is not possible in normal
application: any server using SVNParentPath and svnserve are affected,
because it uses part of URL as repository name. So users accessing
http://server/repo and http://server/REPO will access repository with
different path and get different FS shared data.
--
Ivan Zhakov
CTO | VisualSVN | http://www.visualsvn.com
Re: svn commit: r1589262 - /subversion/trunk/subversion/libsvn_fs_fs/fs.c
Posted by Stefan Fuhrmann <st...@wandisco.com>.
On Wed, Apr 23, 2014 at 1:28 PM, Ivan Zhakov <iv...@visualsvn.com> wrote:
> On 22 April 2014 23:36, <st...@apache.org> wrote:
> > Author: stefan2
> > Date: Tue Apr 22 19:36:12 2014
> > New Revision: 1589262
> >
> > URL: http://svn.apache.org/r1589262
> > Log:
> > Fix a scalability issue with FSFS repositories: The lock mutexes are
> > part of the process-wide per-repo shared structs. Using only the
> > UUID as identification for the repo is not enough in case a repo gets
> > duplicated or the admins don't follow good practice. The result may
> > be serializing all commits globally across all repos.
> >
> > Now, we simply add the normalized repo path to the hash key but keep
> > the UUID as well. The latter allows us to detect and handle replaced
> > repositories gracefully in some cases.
> >
> > * subversion/libsvn_fs_fs/fs.c
> > (fs_serialized_init): Add FS path to the hash lookup key.
> >
> > Modified:
> > subversion/trunk/subversion/libsvn_fs_fs/fs.c
> >
> > Modified: subversion/trunk/subversion/libsvn_fs_fs/fs.c
> > URL:
> http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_fs_fs/fs.c?rev=1589262&r1=1589261&r2=1589262&view=diff
> >
> ==============================================================================
> > --- subversion/trunk/subversion/libsvn_fs_fs/fs.c (original)
> > +++ subversion/trunk/subversion/libsvn_fs_fs/fs.c Tue Apr 22 19:36:12
> 2014
> > @@ -72,19 +72,12 @@ fs_serialized_init(svn_fs_t *fs, apr_poo
> > each separate repository opened during the lifetime of the
> > svn_fs_initialize pool. It's unlikely that anyone will notice
> > the modest expenditure; the alternative is to allocate each
> structure
> > - in a subpool, add a reference-count, and add a serialized
> deconstructor
> > - to the FS vtable. That's more machinery than it's worth.
> > -
> > - Using the uuid to obtain the lock creates a corner case if a
> > - caller uses svn_fs_set_uuid on the repository in a process where
> > - other threads might be using the same repository through another
> > - FS object. The only real-world consumer of svn_fs_set_uuid is
> > - "svnadmin load", so this is a low-priority problem, and we don't
> > - know of a better way of associating such data with the
> > - repository. */
> > + in a subpool, add a reference-count, and add a serialized
> destructor
> > + to the FS vtable. That's more machinery than it's worth. */
> >
> > SVN_ERR_ASSERT(fs->uuid);
> > key = apr_pstrcat(pool, SVN_FSFS_SHARED_USERDATA_PREFIX, fs->uuid,
> > + svn_fs__canonicalize_abspath(fs->path, pool),
> > SVN_VA_NULL);
> Hi Stefan,
>
> I agree that problem is important and should be fixed somehow, but
> committed fix is wrong IMHO:
> 1. svn_fs__canonicalize_abspath is for FS path canonicalization, not
> for disk path
> 2. fs->path is not absolute path, so you may get different keys for
> same repository accessed but different path relative path
> 3. On Windows path names is case insensitive and repository can be
> accessed using 'C:\REPO' and 'C:\repo' path names. Converting path to
> upper case because Windows performs different normalization like
> removing trailing dot and etc. Reimplementing this logic in Subversion
> will be very hard.
>
Alright, do you have a suggestion for how to handle
that problem? Without r1589262, we can't lock the
source *and* target of a hotcopy - which is how I ran
into this issue.
-- Stefan^2.