On 5 Jun 2003, Ben Collins-Sussman wrote:
> 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. :-)
Yes, I see. Revision 6159, right?
> > 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
> "deleted".
>
> 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? :-)
No, that is very helpful. I didn't realise there was a plaintext
``entries'' file in .svn till now. I see it says
deleted="true"
when you commit a deletion.
However, my understanding is that the version of subdir/file1 in the
working copy must not differ in content from the version in the repository
(though it need not be at the same revision) for subversion to allow it to
be deleted. I just did a test and confirmed this for myself. If I try to
commit the deletion of a file in the working copy which is different from
the version in the repository I get
svn: Transaction is out of date
svn: Commit failed (details follow):
svn: out of date: `/thesis/trunk/rr.tex' in txn `12'
svn: Your commit message was left in a temporary file:
svn: '/home/faheem/cotmp/thesis/svn-commit.tmp'
However, I can delete it as long as there are no differences, even if the
revision numbers are different.
So, I'm not sure what you mean in your second option by
"* if a "new" file1 exists in HEAD, the server sends it".
Is the assumption here that someone has restored/reverted the file in a
new revision between your `svn delete' and 'svn up'? Or possibly a
completely different file with the same name? This seems the obvious
possibility, but I'm just checking in case of misunderstanding.
Are under-the-hood details like this documented anywhere outside the
source code?
Faheem.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jun 6 05:52:28 2003