On 8 Jul 2002, Ben Collins-Sussman <sussman@collab.net> wrote:
> Martin, all of these bugs should now be fixed as of r2435.
Sorry, I think they're not.
> And thanks for finding them!
My pleasure. The sooner Subversion is ready to go, the better.
I will try to write a Python test case around this later on. The
testing framework is really clever.
> A bugfix (from me and cmpilato) for what I now dub the "the *reverse*
> ghudson bug". Versioning trees is Hard.
I suppose it's a bit late to mention this, but: have you considered
making commits always tree-wide? It seems to me like that would avoid
some of the "ghudson" problems, and would not significantly reduce
usefulness. If this area has been such a cause of problems in the
past it will continue in the future; if you perform a featurectomy
before 1.0 perhaps noone will miss it. (Just my 2c, etc.)
Using Subversion r2441 (./autogen.sh; ./config.status --recheck; make
clean; make all; make install) tonight:
> mbp/1 svnbug1$ ls -l `which svn`
> -rwxr-xr-x 1 root root 2829782 Jul 9 19:30 /usr/local/bin/svn
> mbp/1 svnbug1$ svn --version
> Subversion Client, version 0.13.2 (dev build)
> compiled Jul 9 2002, 19:28:26
> Copyright (C) 2000-2002 CollabNet.
> Subversion is open source software, see http://subversion.tigris.org/
> The following repository access (RA) modules are available:
> * ra_dav : Module for accessing a repository via WebDAV (DeltaV) protocol.
> - handles 'http' schema
> * ra_local : Module for accessing a repository on local disk.
> - handles 'file' schema
> mbp/1 svnbug1$ svnadmin create repo
> mbp/1 svnbug1$ svn mkdir file:///home/mbp/work/sv
> svn-1611-i386* svnbug1/
> mbp/1 svnbug1$ svn mkdir file:///home/mbp/work/svnbug1/repo/trunk
> Waiting for Emacs...Done
> Committed revision 1.
> mbp/1 svnbug1$ svn co file:///home/mbp/work/svnbug1/repo/trunk
> Checked out revision 1.
> mbp/1 svnbug1$ cd trunk
> mbp/1 trunk$ ls -la
> total 12
> drwxrwxr-x 3 mbp mbp 4096 Jul 9 19:39 .
> drwxrwxr-x 4 mbp mbp 4096 Jul 9 19:39 ..
> drwxrwxr-x 8 mbp mbp 4096 Jul 9 19:39 .svn
> mbp/1 trunk$ svn mkdir foo
> A foo
> mbp/1 trunk$ svn commit -m 'make foo'
> Adding foo
> Committed revision 2.
> mbp/1 trunk$ svn rm foo
> D foo
> mbp/1 trunk$ ls -la
> total 16
> drwxrwxr-x 4 mbp mbp 4096 Jul 9 19:39 .
> drwxrwxr-x 4 mbp mbp 4096 Jul 9 19:39 ..
> drwxrwxr-x 8 mbp mbp 4096 Jul 9 19:39 .svn
> drwxrwxr-x 3 mbp mbp 4096 Jul 9 19:39 foo
> mbp/1 trunk$ svn commit -m 'kill foo'
> Deleting foo
> Committed revision 3.
> mbp/1 trunk$ ls -la
> total 16
> drwxrwxr-x 4 mbp mbp 4096 Jul 9 19:39 .
> drwxrwxr-x 4 mbp mbp 4096 Jul 9 19:39 ..
> drwxrwxr-x 8 mbp mbp 4096 Jul 9 19:39 .svn
> drwxrwxr-x 2 mbp mbp 4096 Jul 9 19:39 foo
> mbp/1 trunk$ svn up
> subversion/libsvn_fs/tree.c:178
> svn_error: #21068 : <Filesystem has no item>
> file not found: transaction `4', path `/trunk/foo'
> mbp/1 trunk$
By the way, is that sequence (svnadmin create; svn mkdir; svn co) the
typical way to start a new repository?
jerenkrantz(?) expressed concern that my svn binary was dynamically
linked against Berkeley db1. It seems very unlikely to me that such a
library problem would have this kind of symptom, as opposed to say
just failing to compile altogether. Looking at the configure output,
I am pretty sure that Subversion itself links against the db4
distribution in a source subdirectory, but APR links against the
system's -ldb and -lgdbm for reasons best know to itself.
--
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jul 9 11:54:21 2002