Re: problem arising from early entry deletion

Karl Fogel <kfogel@newton.ch.collab.net> writes:

> 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. The server, knowing that "foo" doesn't
> exist in 10, could remove "foo" from the svn txn [...]

This is not exactly how it worked, but close. I think this is your
wishful thinking, Karl. :-)

After committing a delete, the client marked the entry merely as
'deleted'. Then when sending an update state-report, it would say "I
have revision 9 of the directory; and also, please delete item 'foo'
from the transaction."

Same idea, really. But I just wanted to make it clear that the client
never claimed to have "revision 10 of foo", because that would
currently make our server choke: "no such path 'foo' in revision 10".

> Principle: "Lying to the server is bad." :-) We need to stop doing it;
> what's the best way?

Not sure about the best solution. Having libsvn_wc track that
'deleted' flag was a huge pain in the $!*@!. Every loop over an
entries file had to deliberately ignore such entries. After commits
and updates completed, we had to make sure the entry vanished. It was
a lot of work. :-(

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Mar 18 03:22:16 2002