On Sun, Jun 29, 2003 at 11:50:12PM -0700, Chris Hecker wrote:
> If there's a possibility of getting screwed up and losing a weekend to a
> problem (like what happened here), then the tool should handle it. Better
The problem is extremely difficult to handle "Right" and without surprise.
It is also a bitch to deal with the case-insensitive filesystems. Believe
me, we've talked about this extensively before. Nobody has dug in to get it
fixed because it is hard to do right. It also doesn't come up all that
often. We've seen maybe four people have problems, and yes: it does cause
> to spend a week implementing a feature in the tool than to spend #users * a
> weekend for all eternity.
Or, hey, how about I throw another equation at you? We deliver 1.0 to people
five weeks sooner and make #users much happier? Which is larger? Personally,
I think more people will take a 1.0 release *first*, then solve the case
> At the very least, svn should know what's going wrong (the files in the
> repository would be the same on the OS that's currently co/up'ing) and tell
> the user (and then they can rename through the URL interface). Randomly
> failing is wrong. It's not that hard to spec out the currently supported
> filesystems and what their constraints are, and require somebody to do that
> for any port target for svn. There should be a spec for what the
> repository stores as well (I assume it follows url rules, which is fine).
There are a lot of "should" statements in there. And a good number of work
items. If you're set on this, then it might be great item for you to tackle
to contribute to the project. Fixing the case-sensitivity problem isn't
going to be rejected, but I don't know that you're going to find a bunch of
people stepping up to the plate (or they would have already).
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.
Greg Stein, http://www.lyra.org/
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Mon Jun 30 09:39:02 2003