[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: "svn move" broken?

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2003-06-06 04:44:01 CEST

Faheem Mitha <faheem@email.unc.edu> writes:

> 1) The deletes sent to the working copy were in fact redundant. So the
> local .svn *was* fully up to date with respect to that. Once this
> buglet has been fixed, no D messages will be sent on doing `svn up' in
> a similar situation.

Yes. And in fact, I fixed the bug today. Just update your source. :-)

> 2) In that case, was the problem only that the revision numbers were
> not synced up to the latest version across the entire directory
> subdir1 (even though the files themselves in this case were up to
> date), so it was just a matter of updating the revision numbers for
> the files in the working copy of that directory (subdir1), and nothing
> else? Since, as you said in another message to this thread:
> 1. you cannot delete a file or directory which isn't at HEAD
> revision in your working copy.

Correct, mostly.

Say subdir1 (and everything inside it) starts out at revision 1.

Now you delete subdir1/file1, and commit the deletion.

What libsvn_wc does is this: it *doesn't* remove the file1 entry from
subdir1's entries file. Instead, it marks the file1 entry as

When you run 'svn update subdir1', libsvn_wc tells the server that you
have revision 1 of subdir1, with file1 already deleted.

The server then compares your working-copy of subdir1 with the HEAD
version of subdir1, and does one of two things:

   * if file1 is also deleted in HEAD, it says nothing; there's no
     differences to send. In which case, libsvn_wc assumes it's
     safe to *completely* remove the file1 entry from the entries
     file, and subdir1 is now marked as being at revision HEAD.

   * if a "new" file1 exists in HEAD, the server sends it. In that
     case, libsvn_wc just installs the new file and overwrites the old
     "deleted" entry. (and again, subdir1 is marked at revision HEAD.)

So the bug that was fixed today was that in certain circumstances, a
commit of three file deletions caused 2 out of 3 file entries to
(prematurely) disappear completely from the entries file. So during
an update, libsvn_wc only reported 1 file as "deleted". The server
then said, "oh, well then, to match HEAD, you also need to delete
these two other files". Hence the two extra no-op deletions you saw.

Too much information? :-)

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jun 6 04:45:46 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.