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

Re: 1.0.7

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2004-09-16 14:35:22 CEST

On Wed, 2004-09-15 at 18:13, Ben Reser wrote:
> Sussman and I think we should do a 1.0.7 tomorrow with the fix for Issue
> #1862. We'd also like to include some of the other fixes in STATUS.
> Please vote ASAP on any issues you want included.

Let me give a more elaborate explanation of the #1862 bug and fix, so
folks can better review and vote for it. It's not that complicated.

To reproduce (using 1.0.X client/server only):
------------

   $ svn co http://localhost/repos/svn/trunk
   [...]
   [control-C partway through]
   A trunk/build/win32/vc6-build.bat.in
   A trunk/build/generator/msvc_dsw.ezt
   subversion/clients/cmdline/main.c:729: (apr_err=200015)
   svn: Caught signal

   $ svn st trunk
   ! trunk
   ! trunk/build
   ! trunk/build/generator

   [okay, we've got some incomplete directories, let's restart the checkout]

   $ svn up trunk/build/generator
   svn: REPORT request failed on '/svn/testrepos/!svn/vcc/default'
   subversion/libsvn_ra_dav/util.c:359: (apr_err=160013)
   svn:
   File not found: transaction '7', path '/trunk/build/generator/ezt.py'

   $ cd trunk; svn up
   [finishes normally]

Why it's happening:
------------------

The update process sends a report of mixed revisions over the network.
On the server end, the 'reporter' vtable listens to the network and
builds a repository transaction tree that mirrors the working copy.
(Again, this is only happening in 1.0; ghusdon rewrote this code in 1.1
so that the mixed-rev report goes into a tmpfile instead.)

When the client has an incomplete directory, it can restart a checkout
or update by saying, "I have this directory, but I have no confidence
that I have all the entries for it. Consider it empty, and I'll tell
you what entries I *do* have."

The "consider it empty" part is the critical thing here: the
libsvn_repos reporter has an accompanying gut_directory() function used
to destroy all children of a directory in the transaction tree. That's
what's buggy. It's deleting the wrong things. It's not aware of
correct anchor/target logic. It's deleting anchor/path, rather than
anchor/target/path. This means it's *only* correct when target=="",
which *only* happens when users run 'svn up' to restart a checkout, no
explicit arguments. But TortoiseSVN always runs 'svn up
/abs/path/to/wc', so there's always a target present, which means the
wrong stuff gets destroyed in the transaction tree. Ergo, the 'file not
found' error later on.

That also explains why commandline 1.0.x users never saw this bug,
because they almost always run 'svn up' to restart checkouts, which
means target really is "", so gut_directory() is accidentally doing the
right thing.

The fix:
-------

Just make gut_directory() aware of anchor *and* target, not just anchor.

Very easy. Take a look. Vote!

This bug is huge... TortoiseSVN folks have been complaining about it for
months and months. Other than case-insensitivity bugs, it's probably
the most visible win32 bug we have. That's why I feel that it justifies
a 1.0.7 release all by itself.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Sep 16 14:37:33 2004

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.