Daniel Berlin wrote:
You assume the tree walker ever sees an entire directory at once, for
starters.
It seems a reasonable assumption that such a tree walker exists or
could be written without too much pain. I can imagine a tree walker
that iterates over file numbers (a la inodes), and that may be most
efficient for some operations. But it's clearly wrong for producing
log/summary/diff output for humans.
Patches welcome :)
Duh. I'm not going to start patching svn. I'm reporting a bug.
I'm not saying anything about the priority of the bug. I think it
should be reported as a formal bug, but I'm not going to do that myself
until I personally witness the buggy behavior, and I don't have
time to try out svn quite yet.
I haven't looked in detail, but i don't believe it's near as simple as
you think, because the structure of how a diff happens isn't what you
think it is.
I'm quite willing to believe some redesign may be needed to fix the bug.
I believe someone is going to try to just store/walk the dirent hash in
a sorted order for now when possible, so that everything above the fs
level just gets handed this stuff in sorted order.
I think that is what I'm proposing.
Protocol changes are no simple matter. We can't just arbitrarily break
the client/server protocol.
There needs to be a graceful fallback for older clients against newer
servers, and the reverse, at least until 2.0.
Hopefully the protocol is somewhat extensible?
In any case, using the client's LC_COLLATE may not be the right thing,
and it's certainly not important.
(I believe someone is working on it to some degree, soon)
Great.
As I said: I don't see this issue as a show-stopper for converting
gcc to svn.
--
--Per Bothner
[EMAIL PROTECTED] http://per.bothner.com/
