You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Kevin Pilch-Bisson <ke...@pilch-bisson.net> on 2002/02/27 18:57:56 UTC
Re: stupid question (after couple of months with subversion)
On Wed, Feb 27, 2002 at 07:59:54PM +0100, Miroslav Zubcic wrote:
> As subject line said, I have very simple or stupid question about
> working with subversion.
>
> Let's say that i have working copy, and I change/add/delete couple of
> files, commit and `svn st' will show me status of working copy.
>
After a commit, svn st should not show anything except '?' files, i.e. ones
that it knows nothing about.
> How can I get clean situation in working copy after that? (No output
> from `st').
>
> Currently I have to revert modified files, delete new added files, and
> that run `svn up' to get all this again from server and to have clean
> situation.
I don't know what may be going on in your case. Can you send a log of some
commands and there output that shows this behaviour.
>
> Is there some /easier/ way to do this? How you guys are doing
> this every-day operations?
>
> Sorry about this simple question on development list, but there is no
> "user" list for subversion/svn AFAIK.
>
>
> --
> This signature intentionally left blank
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Pilch-Bisson http://www.pilch-bisson.net
"Historically speaking, the presences of wheels in Unix
has never precluded their reinvention." - Larry Wall
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Re: stupid question (after couple of months with subversion)
Posted by Ben Collins-Sussman <su...@collab.net>.
Miroslav Zubcic <mv...@crol.net> writes:
> Ben Collins-Sussman <su...@collab.net> writes:
>
> > The only variable that comes to mind is the fact that you're using
> > SSL. We don't use that in production , and *I* have never tried it
> > myself. There's obviously something wrong with the 'post-commit'
> > processing. There are other developers on this list who are using
> > ssl, no? Can they reproduce the problem?
> >
> > One thing that might help, Miroslav, is to send us an HTTP trace of
> > the commit (MERGE) request and the server's response. The server's
> > response is parsed and used to tweak metadata on the committed
> > working-copy files. Maybe there's something wrong with the response.
> > Try tracing the commit with 'ethereal' and sending us the results, if
> > you have time...
>
> I have time for you, of course, but I can't decrypt connection, even
> with ssldump(1) and private key.
>
> OTOH, I have tried this on port 80 *without* https. Same problem.
See sander's reply. Use <Location> instead of <Directory> and try
again.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: stupid question (after couple of months with subversion)
Posted by Miroslav Zubcic <mv...@crol.net>.
Ben Collins-Sussman <su...@collab.net> writes:
> The only variable that comes to mind is the fact that you're using
> SSL. We don't use that in production , and *I* have never tried it
> myself. There's obviously something wrong with the 'post-commit'
> processing. There are other developers on this list who are using
> ssl, no? Can they reproduce the problem?
>
> One thing that might help, Miroslav, is to send us an HTTP trace of
> the commit (MERGE) request and the server's response. The server's
> response is parsed and used to tweak metadata on the committed
> working-copy files. Maybe there's something wrong with the response.
> Try tracing the commit with 'ethereal' and sending us the results, if
> you have time...
I have time for you, of course, but I can't decrypt connection, even
with ssldump(1) and private key.
OTOH, I have tried this on port 80 *without* https. Same problem.
/usr/local/apache2/bin/svn co http://dav.crol.net -d test2
A test2/lala.h
[...]
(mvz){crolvax}[mvz]$ cd test2
(mvz){crolvax}[test2]$ /usr/local/apache2/bin/svn st
(mvz){crolvax}[test2]$ vi lala.h
(mvz){crolvax}[test2]$ /usr/local/apache2/bin/svn st
M ./lala.h
(mvz){crolvax}[test2]$ /usr/local/apache2/bin/svn ci
Sending /home/mvz/test2/lala.h
Committed revision 19.
(mvz){crolvax}[test2]$ /usr/local/apache2/bin/svn st
M ./lala.h
I think we can partialy exclude SSL as bugmaker from this story.
I have trace from session now, Can i send it as attachment on this
list?
--
This signature intentionally left blank
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: stupid question (after couple of months with subversion)
Posted by Ben Collins-Sussman <su...@collab.net>.
Miroslav Zubcic <mv...@crol.net> writes:
> New apache on start says this:
> Apache/2.0.33-dev (Unix) DAV/2 SVN/0.9.0 (rc2) mod_ssl/3.0a0 OpenSSL/0.9.6b
>
> I was thinking - this MUST work, this guys are using it for their
> production, but ...
>
> (maked copy of few random files from apache, added and commited, then
> checkout in another working copy)
>
> (mvz){crolvax}[mvz]$ /usr/local/apache2/bin/svn co https://dav.crol.net -d test1
> mvz's password:
>
> A test1/utils.h
> A test1/regex2.h
> A test1/cclass.h
>
> [... cut ...]
> >
> (mvz){crolvax}[test1]$ /usr/local/apache2/bin/svn ci
> Sending /home/mvz/test1/utils.h
> Committed revision 2.
> (mvz){crolvax}[test1]$ /usr/local/apache2/bin/svn st
> M ./utils.h
>
>
> Argh !!!
>
> I'm willing to try r.1387 or later if you still insist.
>
The only variable that comes to mind is the fact that you're using
SSL. We don't use that in production , and *I* have never tried it
myself. There's obviously something wrong with the 'post-commit'
processing. There are other developers on this list who are using
ssl, no? Can they reproduce the problem?
One thing that might help, Miroslav, is to send us an HTTP trace of
the commit (MERGE) request and the server's response. The server's
response is parsed and used to tweak metadata on the committed
working-copy files. Maybe there's something wrong with the response.
Try tracing the commit with 'ethereal' and sending us the results, if
you have time...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: stupid question (after couple of months with subversion)
Posted by Miroslav Zubcic <mv...@crol.net>.
"Sander Striker" <st...@apache.org> writes:
> > <Directory "/usr/local/apache2/data/sub">
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> This should be <Location /sub>.
That was a bug. With <Location> status is OK, after commit.
> Today a bug was found when <Location /xxx> has a counterpart
> in the DocumentRoot. I'll post the report shortly to the
> httpd list.
What is the difference? How mod_dav_svn is handling this?
--
This signature intentionally left blank
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: stupid question (after couple of months with subversion)
Posted by Sander Striker <st...@apache.org>.
> From: mvz@crol.net [mailto:mvz@crol.net]
> Sent: 28 February 2002 14:49
> To: dev@subversion.tigris.org
> Subject: Re: stupid question (after couple of months with subversion)
>
> > Miroslav Zubcic <mv...@crol.net> writes:
[...]
> Then I created blank new repository with svnadmin(8) in
> /usr/local/apache2/data called "sub" and chown -R apache:apache sub
>
> apache configuration related to subversion is this:
>
> -----------------------------------------------------------
> Listen 443
>
> <VirtualHost 192.168.0.18:443>
> DocumentRoot /usr/local/apache2/data/sub
> SSLEngine on
> SSLCertificateFile /usr/local/apache2/conf/dav-cert.pem
> SSLCertificateKeyFile /usr/local/apache2/conf/dav-key.pem
> SSLVerifyClient none
> ErrorLog logs/dav_err_log
> TransferLog logs/dav_log
> ServerName dav.crol.net:443
> ServerAlias dav
> DavLockDB /tmp/DavLock
> <Directory "/usr/local/apache2/data/sub">
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This should be <Location /sub>.
Today a bug was found when <Location /xxx> has a counterpart
in the DocumentRoot. I'll post the report shortly to the
httpd list.
> DAV svn
> SVNPath /usr/local/apache2/data/sub
> AuthType Basic
> AuthName "Subversion repository on CRoL"
> AuthUserFile /usr/local/apache2/data/.htpasswd
> # <LimitExcept GET PROPFIND OPTIONS REPORT>
> require valid-user
> # </LimitExcept>
> AllowOverride None
> order deny,allow
> deny from all
> allow from 192.168.0.0/24
> </Directory>
[...]
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: stupid question (after couple of months with subversion)
Posted by Miroslav Zubcic <mv...@crol.net>.
Ben Collins-Sussman <su...@collab.net> writes:
> Miroslav Zubcic <mv...@crol.net> writes:
> > RedHat Linux 2.4.14, glibc 2.2.4.
> > Apache/2.0.31-dev (Unix) DAV/2 SVN/0.8.0 mod_ssl/3.0a0 OpenSSL/0.9.6b
> >
> > Don't remember all but here is build history:
> >
> > compiled static BerkeleyDB 4.
> > compiled apache2 with OpenSSL
> > compiled subversion with neon in his directory, and paths to
> > BerkeleyDB and apr.
> >
> > I can try to build newer subversion apache module today and see ...
> Yes, please let us know if you can reproduce these bugs using
> subversion r.1387 or later.
Too late. I just build r1329 with
* httpd-2.0: from 2002-02-19
* apr: from 2002-02-19
* apr-util: from 2002-02-19
... and neon-0.18.5
Just like svn.collab.net has. - Still no luck!
Build was this:
mkdir subbuild
cd !$
cp ~/sources/http-2.0 .
cp ~/sources/apr .
cp ~/sources/apr-util .
tar xvzf ~/sources/neon-0.18.5.tar.gz
cp -a ~/sources subversion-r1329 .
cd httpd-2.0/srclib
ln -s ../../apr .
ln -s ../../apr-util .
cd ..
./buildconf
./configure --enable-ssl --with-berkeley-db=/usr/local/subv \
--with-dbm=db4 --disable-auth-db --enable-auth-digest \
--enable-file-cache --enable-echo --enable-cache \
--enable-mem-cache --enable-ext-filter --enable-example \
--enable-case-filter --enable-mime-magic --enable-expires \
--enable-headers --enable-usertrack --enable-unique-id \
--enable-proxy --enable-proxy-connect --enable-proxy-ftp \
--enable-proxy-http --enable-cgi --enable-dav-fs \
--enable-vhost-alias --enable-rewrite --enable-so \
--enable-suexec --enable-cgi --enable-mods-shared=all
make
make install # (in _CLEAN_ /usr/local/apache2 destination)
cd ../subversion-r1329
ln -s ../apr .
ln -s ../apr-util .
ln -s ../neon-0.18.5 neon
sh autogen.sh
export CPPFLAGS="-DNEON_SSL"
./configure --prefix=/usr/local/apache2 \
--with-apxs=/usr/local/apache2/bin/apxs \
--with-berkeley-db=/usr/local/subv --with-ssl
make
make install
Then I created blank new repository with svnadmin(8) in
/usr/local/apache2/data called "sub" and chown -R apache:apache sub
apache configuration related to subversion is this:
-----------------------------------------------------------
Listen 443
<VirtualHost 192.168.0.18:443>
DocumentRoot /usr/local/apache2/data/sub
SSLEngine on
SSLCertificateFile /usr/local/apache2/conf/dav-cert.pem
SSLCertificateKeyFile /usr/local/apache2/conf/dav-key.pem
SSLVerifyClient none
ErrorLog logs/dav_err_log
TransferLog logs/dav_log
ServerName dav.crol.net:443
ServerAlias dav
DavLockDB /tmp/DavLock
<Directory "/usr/local/apache2/data/sub">
DAV svn
SVNPath /usr/local/apache2/data/sub
AuthType Basic
AuthName "Subversion repository on CRoL"
AuthUserFile /usr/local/apache2/data/.htpasswd
# <LimitExcept GET PROPFIND OPTIONS REPORT>
require valid-user
# </LimitExcept>
AllowOverride None
order deny,allow
deny from all
allow from 192.168.0.0/24
</Directory>
SetEnvIf User-Agent ".*MSIE.*" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0
CustomLog logs/ssl_request_log \
"%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
<Files ~ "^\.ht">
Order allow,deny
Deny from all
</Files>
</VirtualHost>
--------------------------------------------------------------------
No errors in logs/dav_log
New apache on start says this:
Apache/2.0.33-dev (Unix) DAV/2 SVN/0.9.0 (rc2) mod_ssl/3.0a0 OpenSSL/0.9.6b
I was thinking - this MUST work, this guys are using it for their
production, but ...
(maked copy of few random files from apache, added and commited, then
checkout in another working copy)
(mvz){crolvax}[mvz]$ /usr/local/apache2/bin/svn co https://dav.crol.net -d test1
mvz's password:
A test1/utils.h
A test1/regex2.h
A test1/cclass.h
[... cut ...]
(mvz){crolvax}[mvz]$ cd test1
(mvz){crolvax}[test1]$ /usr/local/apache2/bin/svn st
(mvz){crolvax}[test1]$ vi utils.h
(mvz){crolvax}[test1]$ /usr/local/apache2/bin/svn diff
Index: ./utils.h
===================================================================
--- ./utils.h
+++ ./utils.h Thu Feb 28 14:42:08 2002
@@ -20,3 +20,5 @@
#ifdef USEBCOPY
#define memmove(d, s, c) bcopy(s, d, c)
#endif
+
+/* blablabla */
(mvz){crolvax}[test1]$ /usr/local/apache2/bin/svn ci
Sending /home/mvz/test1/utils.h
Committed revision 2.
(mvz){crolvax}[test1]$ /usr/local/apache2/bin/svn st
M ./utils.h
Argh !!!
I'm willing to try r.1387 or later if you still insist.
--
This signature intentionally left blank
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: stupid question (after couple of months with subversion)
Posted by Ben Collins-Sussman <su...@collab.net>.
Miroslav Zubcic <mv...@crol.net> writes:
> Ben Collins-Sussman <su...@collab.net> writes:
>
> > > > (mvz){crolvax}[proba-01]$ svn ci
> > > > Adding /home/mvz/proba-01/file001
> > > > Sending /home/mvz/proba-01/foo.c
> > > > Committed revision 29.
> > > > (mvz){crolvax}[proba-01]$ svn st
> > > > A ./file001
> > > > M ./foo.c
>
> > > Whoa. That's ... uh ... broken, dontcha think? I wonder what could
> > > be happening here...
>
> > That is *way* broken. After a commit, you shouldn't be seeing those
> > 'A' and 'M' codes anymore. They should have each been bumped to
> > working revision 29!
>
> > Miroslav, what platform are you running on? Give us the history of
> > your subversion build. (Can anyone else reproduce this?)
>
> RedHat Linux 2.4.14, glibc 2.2.4.
> Apache/2.0.31-dev (Unix) DAV/2 SVN/0.8.0 mod_ssl/3.0a0 OpenSSL/0.9.6b
>
> Don't remember all but here is build history:
>
> compiled static BerkeleyDB 4.
> compiled apache2 with OpenSSL
> compiled subversion with neon in his directory, and paths to
> BerkeleyDB and apr.
>
> I can try to build newer subversion apache module today and see ...
Yes, please let us know if you can reproduce these bugs using
subversion r.1387 or later.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: stupid question (after couple of months with subversion)
Posted by Miroslav Zubcic <mv...@crol.net>.
Ben Collins-Sussman <su...@collab.net> writes:
> > > (mvz){crolvax}[proba-01]$ svn ci
> > > Adding /home/mvz/proba-01/file001
> > > Sending /home/mvz/proba-01/foo.c
> > > Committed revision 29.
> > > (mvz){crolvax}[proba-01]$ svn st
> > > A ./file001
> > > M ./foo.c
> > Whoa. That's ... uh ... broken, dontcha think? I wonder what could
> > be happening here...
> That is *way* broken. After a commit, you shouldn't be seeing those
> 'A' and 'M' codes anymore. They should have each been bumped to
> working revision 29!
> Miroslav, what platform are you running on? Give us the history of
> your subversion build. (Can anyone else reproduce this?)
RedHat Linux 2.4.14, glibc 2.2.4.
Apache/2.0.31-dev (Unix) DAV/2 SVN/0.8.0 mod_ssl/3.0a0 OpenSSL/0.9.6b
Don't remember all but here is build history:
compiled static BerkeleyDB 4.
compiled apache2 with OpenSSL
compiled subversion with neon in his directory, and paths to
BerkeleyDB and apr.
I can try to build newer subversion apache module today and see ...
--
This signature intentionally left blank
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: stupid question (after couple of months with subversion)
Posted by Ben Collins-Sussman <su...@collab.net>.
cmpilato@collab.net writes:
> Miroslav Zubcic <mv...@crol.net> writes:
>
> > OK here is a little example:
> >
> > (mvz){crolvax}[proba-01]$ svn st
> > (mvz){crolvax}[proba-01]$ vi foo.c # editing existing file ...
> > (mvz){crolvax}[proba-01]$ echo "blablabla" > file001
> > (mvz){crolvax}[proba-01]$ svn st
> > ? ./file001
> > M ./foo.c
> > (mvz){crolvax}[proba-01]$ svn add file001
> > (mvz){crolvax}[proba-01]$ svn ci
> > Adding /home/mvz/proba-01/file001
> > Sending /home/mvz/proba-01/foo.c
> > Committed revision 29.
> > (mvz){crolvax}[proba-01]$ svn st
> > A ./file001
> > M ./foo.c
> > (mvz){crolvax}[proba-01]$ svn revert file001 mangle.c
> > Reverted file001
> > Reverted mangle.c
>
> Whoa. That's ... uh ... broken, dontcha think? I wonder what could
> be happening here...
That is *way* broken. After a commit, you shouldn't be seeing those
'A' and 'M' codes anymore. They should have each been bumped to
working revision 29!
Miroslav, what platform are you running on? Give us the history of
your subversion build. (Can anyone else reproduce this?)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: stupid question (after couple of months with subversion)
Posted by cm...@collab.net.
Miroslav Zubcic <mv...@crol.net> writes:
> OK here is a little example:
>
> (mvz){crolvax}[proba-01]$ svn st
> (mvz){crolvax}[proba-01]$ vi foo.c # editing existing file ...
> (mvz){crolvax}[proba-01]$ echo "blablabla" > file001
> (mvz){crolvax}[proba-01]$ svn st
> ? ./file001
> M ./foo.c
> (mvz){crolvax}[proba-01]$ svn add file001
> (mvz){crolvax}[proba-01]$ svn ci
> Adding /home/mvz/proba-01/file001
> Sending /home/mvz/proba-01/foo.c
> Committed revision 29.
> (mvz){crolvax}[proba-01]$ svn st
> A ./file001
> M ./foo.c
> (mvz){crolvax}[proba-01]$ svn revert file001 mangle.c
> Reverted file001
> Reverted mangle.c
Whoa. That's ... uh ... broken, dontcha think? I wonder what could
be happening here...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: stupid question (after couple of months with subversion)
Posted by Miroslav Zubcic <mv...@crol.net>.
Kevin Pilch-Bisson <ke...@pilch-bisson.net> writes:
> > Let's say that i have working copy, and I change/add/delete couple of
> > files, commit and `svn st' will show me status of working copy.
> After a commit, svn st should not show anything except '?' files, i.e. ones
> that it knows nothing about.
...
> > Currently I have to revert modified files, delete new added files, and
> > that run `svn up' to get all this again from server and to have clean
> > situation.
> I don't know what may be going on in your case. Can you send a log of some
> commands and there output that shows this behaviour.
OK here is a little example:
(mvz){crolvax}[proba-01]$ svn st
(mvz){crolvax}[proba-01]$ vi foo.c # editing existing file ...
(mvz){crolvax}[proba-01]$ echo "blablabla" > file001
(mvz){crolvax}[proba-01]$ svn st
? ./file001
M ./foo.c
(mvz){crolvax}[proba-01]$ svn add file001
(mvz){crolvax}[proba-01]$ svn ci
Adding /home/mvz/proba-01/file001
Sending /home/mvz/proba-01/foo.c
Committed revision 29.
(mvz){crolvax}[proba-01]$ svn st
A ./file001
M ./foo.c
(mvz){crolvax}[proba-01]$ svn revert file001 mangle.c
Reverted file001
Reverted mangle.c
(mvz){crolvax}[proba-01]$ svn up
U ./foo.c
svn_error: #21029 : <Obstructed update>
Can't add 'file001':
object of same name already exists in '.'
(mvz){crolvax}[proba-01]$ rm -f file001
(mvz){crolvax}[proba-01]$ svn up
A ./file001
(mvz){crolvax}[proba-01]$ svn st
(mvz){crolvax}[proba-01]$ svn --version
Subversion Client, version 0.9.0 (rc2)
compiled Feb 16 2002, 12:19:07
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
- handles 'https' schema
--
This signature intentionally left blank
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org