Ben Collins-Sussman <sussman@collab.net> writes:
> 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".
Oh yah, I knew the client just said "delete foo", not "I have rev 10
of foo, which you know doesn't exist"... But I thought the client did
bump the revision on the deleted entry, no? That is, the client knew
what revision it deleted foo in, even if the client didn't tell that
revision to the server, right?
> 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. :-(
Well, that stuff was all done, right? It was some other cause that
led us to drop the `deleted' flag, but what was that reason? Hmmm...
I don't, personally, see any way to avoid reverting to using the flag,
but maybe there's some other solution. Anyway, "difficult", while
bad, is still infinitely better than "blatantly incorrect", which I
think accurately describes the status quo. :-)
-K
---------------------------------------------------------------------
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:53:26 2002