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

Re: [DESIGN] svn:resolve-case

From: Joshua Varner <jlvarner_at_gmail.com>
Date: 2005-08-24 07:01:18 CEST

On 8/22/05, Branko ╚ibej <brane@xbc.nu> wrote:> Your proposal talks about imposing a file naming policy. What I said is> that this won't fix problems that arise from faulty detection of> case-conflicts in the working copy.
I think I may be seeing some of the difficulty we are havingagreeing on what the problem is and how to fix it. I see thebug you are talking about as part of a larger problem. Havinga naming policy of non-case conflicting files is necessary forany project that can be checked out on NCS filesystems.Additionally the clients on NCS systems need to have extrabehavior related to case issues.
> Simply put, your proposal wouldn't fix the problem, it would just make> one cause of the problem less likely to happen. And judging by the> various reports I've seen, it's not the most important cause.
First, there is the "buggy" behavior of programs on NCS platformsthat may change the case of a file. This, to my admittedly limitedunderstanding, is only a problem once the client tries tocommunicate with the server. That is: working copy only actionsare not affected.
A quick survey of the issue tracker shows these bugs as activeproblems related to case. Issue 667: Case only renames fail (Other case related edge case)Issue 1495: similar to 667, but also problems with file:// URLs on WindowsIssue 2010: Checkout fails on NCS, when directory contain two files differing only in case
None of these are the case we are talking about. That, also, needsto be resolved. Since this machinery needs to be built into theclient libraries anyway, why not tie it to an optional behavior onCS systems to help avoid accidentally adding two files that differonly by case.
So, in addition to the properties proposed, machinery to check casing,and resolve changes, needs to be added into the client libraries tocorrect any inadvertent changes prior to communicating with the server.
I may have erred too far on the side of generalization. The preserve/initialcase may be the only behavior desired, but this should be an option/propertyas a convenience on CS systems.
Does this put us back on the same page?
Josh
Received on Wed Aug 24 07:03:09 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.