On Sun, 2002-03-17 at 21:07, Karl Fogel wrote:
> So now, instead of keeping the entry, but marking it as being at the
> new revision and having the `deleted' flag, we just remove the entry.
> I believe this can lead to a serious bug, one that we haven't
> encountered yet but which will bite us eventually.
Ah, yes, one of the Greg Hudson Problems.
> But nowadays, the result of that command would simply be
>
> "." : rev=9
> "bar": rev=9
> "baz": rev=9
The easiest way to see how this is broken is to think about what happens
when you do "svn update -r 9". The client transmits a report saying
that . is at rev 9 with no exceptions, and the server (obviously) tells
the client that nothing needs to be done. But that's broken; in rev 9
there was a file "foo" in the current directory.
> In the old days, the client would have sent a working copy state
> report claiming that "." is at revision 9, while entry "foo" is at rev
> 10, in which it is deleted.
Ben pointed out that we actually would say just that foo was deleted,
because the server doesn't like seeing a revision where the file doesn't
exist. I wonder if our code would be simpler than it was before if we:
* Used the revision number where the file doesn't exist, instead of
the "deleted" flag. The non-existence of a text-base would communicate
to the WC that the file does not exist at that rev. (Error-prone?
Maybe. If we keep checksums of the text-base file, and we probably
should, then that bit of state could also have a distinguished value
which corroborates the nonexistence of the text-base.)
* Modified our server not to complain in this case. (The code in
question is dealing with a custom report, yes? So there's no WebDAV
issue.)
Alas, I don't understand the relevant bits of code well enough to say.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Mar 18 16:11:13 2002