[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: problem arising from early entry deletion

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2002-03-18 16:10:32 CET

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

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

This is an archived mail posted to the Subversion Dev mailing list.