On Thu, 2006-07-27 at 03:55 -0400, John Szakmeister wrote:
> ----- Tom Vaughan <tom@creativedigitalsys.com> wrote:
> [snip]
> > How is that? This goes back to my original question of bumping up the
> > revision number in the repository so it is at least n + 1, where n is
> > the biggest repository number any one could have, and I know what that
> > number is. It's the number I have checked out.
>
> The problem lies in the fact that we communicate to the server by sending deltas. We do this to save (considerable) bandwidth. Now that you've lost some revisions, introduced some new empty ones, the deltas that will get generated between your revision and head could lead to a completely unusable working copy (you might suffer data corruption). For instance, say your working copy is at r100, and the head revision is at 110. The server crashed, and the latest backup you had was only r99. But someone had r110 still around in a working copy. So you scoop it up, insert 10 empty revisions, and commit the latest code. Now your server is back at r110. Now you go to do 'svn up'. The client will report your working copy as being at r100. Subversion is smart, so it'll say, "okay, r99 and r100 are the same" because r100 was an empty revision. The server will then compute the delta between r99 and r110, and send that back to update the working copy. However, that's not really the same as what the delta wou
ld have been between r100 and r110 before the server crash. What you'll end up with is the diff of r99 and r110 being applied to every working copy that is at one of the empty revisions. That's obviously not correct, and will corrupt the data in your working copy (corrupt in the sense that it doesn't produce r110).
>
> Hope that helps.
Yup. That's helps. Thanks.
-Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jul 27 18:47:51 2006