On 8/22/05, Branko Èibej <brane@xbc.nu> wrote:> Joshua Varner wrote:> > >PROPERTIES> >> >svn:resolve-case> > If svn:resolve-case is set on a directory then all filenames passed> > between the file system and the svn server should be munged into a> > "resolved" form. This property make take several values:> >> > force-lower - All filenames are stored as lowercase in the> > repository> > initial - All filenames are stored in the case in which they> > existed on addition to the repository> > . . . (others Initial Capital, Upper, needs to be a short list)> > empty - Check for svn:case-folded> >> >svn:case-folded> > File property that, when set and the file exists in a directory with> > svn:resolve-case set, uses its value to override the heuristic> > set by svn:resolve-case.> >> >> I must admit that I have no idea how this is supposed to fix> case-conflict problems on NCS filesystems. These properties look like> they're enforcing some kind of project policy, not fi
xing case-conflict> problems.> > The catch is that you have to _detect_ case conflicts or case-only> changes on the client, in the working copy, not when you're reading> files from the server.> > >ERROR RECOVERY> > When a directory is checked out - the client should check if the names> > violate the svn:resolve-case property, and if so throw an error indicating> > to the users that a conflict exists. Case sensitive file systems may be> > to finish downloading the directory, and then fix the problem in their> > working copy, but this adds extra complexity and it would be simpler to> > just abort and make the user resolve the problem with URLs. Additionally,> > adds and moves should check for name conflicts when svn:resolve-case> > is set.> >> >> This again doesn't aid towards solving the underlying problem, which is,> detecting case change (or conflict) in general on the client. I can't> see how adding these properties would make anyone's life easier.> > If you want to enforce a certain file naming co
nvention, you can do that> far more flexibly in a pre-commit hook on the server. By setting a> policy, you can avoid most (if not all) case-change problems that happen> when you add files on different clients (with different case-sensitivity> properties of the filesystem). But you can't avoid problems that stem> from case-only renames on files on NCS filesystems -- and these, I> believe, are the most insidious.>
By this argument, the best place to enforce end-of-line conventions is onthe server as well. The properties do not fix the problem, just like theeol properties do not fix that problem. The client changes its behavior inthe presence of this property. The actual detection and resolution of eoland case issues should be in the client software.
Ask anyone who has committed a file with CR-LFs in it, then added an eolproperty to it by URL. Does their next checkout have the resolved ending?No, you have to check out the file, and then recommit it so that the clientcan resolve the endings before creating the transaction.
You could get the same behavior of an eol property, by creating a hookscript that rejects any commit with the wrong encoding, too. But it is because of the common nature of this conversion, and the ease of handlingit, that a property exists to tell the clients to fix the problem automatically.
The same scope vs. complexity issues arise when talking about case aswhen talking about eol. Its still the same two basic camps MS vs *nix.Personally I use linux, I just want to help get this resolved, because anumber of users have problems and inconveniences related to the issue.
The other issue that is brought up frequently with a server side hook, isthat you would have to exhaustively search all of the locales and weirdlocale behaviors/bugs of the client environments, which does not makefor a simple process. Thus pushing this down to the client level allows aclient (which must know what OS/file system it is operating on) to handlelocale/casing issues when it gets data from the server and when it sendsit back.
Josh
Received on Tue Aug 23 02:58:12 2005