Philip Martin <firstname.lastname@example.org> writes:
> No major difficulty? In other words "you overlooked something
> obvious". You are becoming *very* annoying.
> I'll give it one last go: if you want to help fix this you need to
> work out what to do. That's not just some vague hand waving about
> setting properties to control the client/server behaviour. You need
> to examine how the libsvn_wc library handles files in the physical
> filesystem, you need determine what goes wrong when the filesystem is
> case-insensitive, you can ask questions about the current code if you
> need to, and then you need to propose some changes to the library.
> So far your contributions have been little more than noise.
Yeah. I can understand why Philip is getting annoyed :-(.
Gili, the reason I asked you to post here was so we could remember why
the seemingly-obvious solutions had not been done, not so we could be
accused of having "placed this issue as a lower priority" despite it
being "no major difficulty". If only things were that easy!
Now we have the information, thanks to Philip Martin and Greg Hudson:
* 'svn mv ABC abc' is hard because the two files have to live in
.svn/text-base/ simultaneously for a while. There are solutions
to this, but they involve making notoriously complex libsvn_wc
even more complex. This is always something we approach with
* Receiving case-only changes via update is hard because add of the
new file arrives before the delete of the old file. Again, there
may be solutions to this, but a lot of thought and testing is
required. The order in which things happen during an update is
hardly random, so it's not like we can just change that order and
assume everything's going to be fine.
A constructive thing you could do would be to annotate issue #667 with
this information, and with a pointer to this thread, and ideally
pointers to the specific messages within this thread that contain hard
(An even more constructive thing would be a patch, of course, or the
type of code-questioning discussion that precedes a patch. But I
completely understand if you don't have time for that; updating the
issue would be the next best thing.)
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Fri Dec 24 02:18:17 2004