[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Bad bug in the Windows Client? (Case issue - duplicate files)

From: James FitzGibbon <jfitzgibbon_at_primustel.ca>
Date: 2005-06-07 20:59:48 CEST

In this specific case, the error message that the contrib hook generates is
quite informative:
Transmitting file data .svn: Commit failed (details follow):

svn: MERGE request failed on '/PISG-DA-DCH/trunk'

svn: 'pre-commit' hook failed with error output:

File name case conflict found:

PISG-DA-DCH/trunk/Makefile.pl already exists as Makefile.PL

And of course you can customize it further if you wish to make it clear that
the error is policy-driven. In fact, given that the "out of the box" hooks
in svn are either rudimentary or present for example purposes only, I think
that it is expected that anyone using them is going to do a little

When you suggest a server-side property, isn't that really what a server
hook is? Properties in svn are attached to individual items (well,
excluding revprops), so if you were to truly do this with properties you
would have to ensure that the property was set on every new file, which I
think would be more problematic because it would require every client to
have auto-props turned on and configured correctly (at least until the
server-pushed client configuration discussion levels out and an
implementation arises).

Something that enforces policy on a repository as a whole (or more
specifically on an action taken against a repository) should be taken care
of in hooks.



From: Brad [mailto:svn@molandernet.com]
Sent: Tuesday, June 07, 2005 2:35 PM
To: Scott Palmer
Cc: users@subversion.tigris.org
Subject: Re: Bad bug in the Windows Client? (Case issue - duplicate files)

    I figure at the minimum, the windows client should notice during
checkout and inform the user of the actual problem. The error that I
received, was a file not found error. It could simply print out that there
is an incompatibility between file systems and that it is unable to checkout
or update that particular directory.

    Of course preventing this situation could be solved by having a server
side property set that would allow or disallow case insensitive filename
matches. I for one would rather this be turned on by default given the user
base of windowsXP clients. I would think that the majority of subversion
clients are unfortunately windows based and thus should dictate the default.
But at the minimum a property would be very useful.

    Sometimes commit hooks aren't all that great because of the amount of
information returned to a user. Some users, that are not familiar with
subversion can have trouble distinguishing between a subversion error and a
"business" error. I wish there was a basic text formatting language or a
cleaner return message to generic clients.

Anyways, thanks for the help!


On Tue, 2005-06-07 at 14:23 -0400, Scott Palmer wrote:

On Jun 7, 2005, at 1:53 PM, Brad wrote:

I have encountered a severe problem with subversion in windowsXP.

I believe a user copied over a file called temp.JPG that they wanted to add
to subversion, however another file, temp.jpg already existed. Windows
overwrote the old one, subversion thought it was a new file and allowed the
user to add it. Once the file was committed,

It appears that users can commit files with the same names in different
"cases". Linux handles this just fine, but windowsXP does not. Currently any
user that tries to checkout from the repository in windows will get an error
and cannot proceed. Even once I fix this, around 2 dozen revisions will
already be "un-checkout-able" for them.

Shouldn't subversion have the ability to prevent this?

Yes, it should.

Does it already?

No, it doesn't - at least not out of the box.

Do I need to create a hook?


I need a way to prevent hundreds of users from doing this, many of which are
not computer literate. Any ideas?

Use a pre-commit hook that rejects commits that will result in files in the
repository that only differ by case.


No virus found in this incoming message.
Checked by AVG Anti-Virus.
Version: 7.0.323 / Virus Database: 267.6.5 - Release Date: 6/7/2005
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.323 / Virus Database: 267.6.5 - Release Date: 6/7/2005
This electronic message contains information from Primus Telecommunications
Canada Inc. ("PRIMUS") , which may be legally privileged and confidential.
The information is intended to be for the use of the individual(s) or entity
named above. If you are not the intended recipient, be aware that any
disclosure, copying, distribution or use of the contents of this information
is prohibited. If you have received this electronic message in error, please
notify us by telephone or e-mail (to the number or address above)
immediately. Any views, opinions or advice expressed in this electronic
message are not necessarily the views, opinions or advice of PRIMUS.
It is the responsibility of the recipient to ensure that
any attachments are virus free and PRIMUS bears no responsibility
for any loss or damage arising in any way from the use
thereof.The term "PRIMUS" includes its affiliates.
Pour la version en franšais de ce message, veuillez voir
Received on Tue Jun 7 21:02:15 2005

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.