> > Erik Huelsmann wrote:
> > >
> > > How do you propose to solve the problem that 2 different
> > > files map to the
> > > same filesystem object?
> > Recognise this is a case-blind filesystem, and deal with it. It's
> > special-case code, but then it is a special case.
> I was actually not asking you to tell me to deal with it, but
> I was asking
> what you consider good behaviour for the Subversion client
> when dealing with
> it. I can't feed "Deal with it" to a C compiler and expect a working
Sorry, on re-reading, I agree that was a rather unhelpful response.
However, it's difficult to make concrete suggestions without knowing
the internals of the code (and I don't currently have time to get
familiar enough). So the following is guesses based on what I've
picked up from watching this list and the dev list.
I think there are three different cases to consider:
1. The effect on the working copy when the move is done.
2. The effect on the working copy of an update which passes one
of these renames.
3. Handling of the case where there really are two files committed
in the repository with the same name but different case.
For 1 and 2, the only reason for having the deleted file still there
is to preserve data (as far as I can tell). You still have the data,
so the WC metadata could just point both of them at the same file.
It would need to know not to delete the file until all references
were gone, but I think that's the main gotcha. Of course, maybe the
WC metadata doesn't really support this easily... For 2, there is also
my original proposal of doing the delete first.
For 3, yes, give me an error. If one of my colleagues is working on
the Linux version and has committed two files which differ only in
case, and it's code I need on Windows as well, we've got a problem
anyway, so I'd like Subversion to tell me. However, in that scenario,
developers should be aware that it's a bad thing to do, so
realistically it's not going to happen often.
I hope this is more helpful. If I've completely misunderstood some
feature of the metadata which makes this unfeasible, so be it.
Senior Applications Software Engineer
e: email@example.com / firstname.lastname@example.org
t: +44 131 272 7145
f: +44 131 272 7001
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Thu Sep 2 10:32:24 2004