>I'm not uncaring about the issue, but understand that I'd prefer to see 1.0
>sooner rather than later (so I won't be working on it, personally). There
>are certain edge cases that just won't be fixed by a 1.0 release unless
>additional people throw in some assistance.
This is totally fair. I'm going to fix the win32 ~/.subversion thing
first, if I end up contributing, because hey, it sticks in my craw. My
point was just that this is a valid complaint, and something that should be
in svn. Several of the replies were saying it shouldn't be part of svn,
which is wrong in my opinion. It's totally valid to say "unless somebody
steps up to the plate this won't make 1.0 because of resources and
priorities", but it's not valid to say "this should be user policy",
because it hoses people silently. That attitude was all I was
protesting. Obviously "should" doesn't get things done.
I wonder if there's a simple way to get 80% of the way there for very
little work. Boil down all the currently supported filesystem constraints
(unix, win32, mac, vms?) into a single check, and just issue a warning
(that's both disablable and errorizable) if you violate any of them during
add, rename, import, etc ("warning: %s could have conflicts on some
filesystems" or whatever). So, it would check for the union of illegal
chars, file name lengths, path lengths, case sensitivity, etc. It would
attempt to do a thorough job, but it wouldn't be perfect. It would get all
of the obvious low-hanging fruit, however. Would there be an easy single
choke point for this function to be called to validate a new potential
filename? Would it have to live on the server, or could it live on the
client and still work?
Perhaps somebody affected by this can chip in and write the function if
they have a more experienced svn person point them in the right direction.
Chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jun 30 10:16:36 2003