Mark Phippard <markp...@gmail.com> writes: > Suppose I am using this feature for binaries, which I think is the > main use case. Using whatever tool I produce a modified version of my > binary file. At this point in time, there is nothing in the text-base > because I have not done any SVN operations other than checkout. Since > it is a binary, other than maybe running status my next likely command > is going to be commit. Are you saying that during the processing of > this commit the client will first fetch the original text base from > the server before doing the commit? That seems sub-optimal. Perhaps > you are only doing this for diff or revert which would make perfect > sense?
The current state is that the commit is going to fetch the original text-base before sending the delta. It should be technically possible to implement a behavior where the commit sends a delta if the local text-base is present, and a fulltext otherwise. (Although as far as I can tell, we would have to extend the delta editor to allow us to send a fulltext against an existing file, and the optimization would only work for newer servers.) But at this point, I'm not too sure that we should make the commit special in that aspect. This optimization is only going to work reliably if the only things you do is checkout and commit. Because an update with modified files is going to fetch those text-bases by itself. And the update itself could happen in response to trying to do an out-of-date commit. > Aside from all of that ... do the text bases get cleaned up? For > example at the end of a successful commit does it get rid of that text > base that no longer are current? Yes. The text-base file corresponding to the new version of the file is not going to be written to the disk. The text-base file corresponding to the old version gets cleaned up if it is not referenced by any other remaining modified files. Thanks, Evgeny Kotkov
