Greg Hudson ghudson@MIT.EDU writes:
I'll put this another way. Consider the following sequence:
* I issue a checkout for a very large directory.
* I interrupt it just after it creates the top-level directory.
* I cd inside the directory and update.
* I interrupt the update 30% of the way through.
* I update again.
Does anything inefficient happen? If so, we have a problem with
updates. If not, then why didn't we take Luke's suggestion?
Updates of valid working copies are already designed to be restartable
(if they aren't, then there are implementation bugs to work out). In
the scenario you gave above:
* I issue a checkout for a very large directory.
* I interrupt it just after it creates the top-level directory.
Alright. Using my method, you have an entries file that contains all
its entries, but they are all missing from disk. You should still
have a completely valid working copy.
* I cd inside the directory and update.
The update routines will read your entries file, note that you have N
dirents. It will then read the disk. Using my method, it will report
what you don't have. Using Luke's, what you have. As far as
reporting goes, the efficiency prize is a draw, depending on whether
or not you have more than or less than half of the dirents completely
checked out.
* I interrupt the update 30% of the way through.
* I update again.
Alright. As we said, updates of valid working copies were designed to
be restartable. Should be no problem here.
Luke's suggestion is a fine implementation -- I just would prefer to
*lose* interfaces in light of the opportunity to use (and I don't mean
mis-use, I mean use) existing ones. It does look like there are some
working-copy problems that occur when you have nothing but the entry
for a missing thing (no text-base, no prop-base, no working file), but
those are likely real bugs that should be fixed anyway.
But whatever; I'm not implementing the solution.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 14 02:21:35 2006