Re: Subversion Exception!

[Ulrich Eckhardt]

Am 02.11.2011 22:35, schrieb Sandeep Seshadri:

Please take the time to report this on the Subversion mailing list


Thank you for that!



with as much information as possible about what you were trying to do.

  
Please do this, the next time.



But please first search the mailing list archives

 ^^

And please do this, too, next time.



'D:\Development\SVN\Releases\TortoiseSVN-1.7.0\ext\subversion\subversion\libsvn_wc\workqueue.c'
line 672: assertion failed (checksum != NULL)


This has been reported ~100 times since the 1.7.0 release.

Remedies:
 * Get a new checkout.
 * Upgrade to 1.7.1

Uli

**
Domino Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
**
Visit our website at http://www.dominolaser.com
**
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten 
bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen 
Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein 
sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, 
weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte 
Änderungen enthalten. Domino Laser GmbH ist für diese Folgen nicht 
verantwortlich.
**

svn 1.7.1 for Windows/64bit - cannot perform svn update

[Tomáš Klinkovský]

Hello,

starting from svn 1.7 I cannot make "svn update" anymore on Windows 7, 
64bit.


C:\Users\tomas\Documents\xxx>svn --version
svn, version 1.7.1-SlikSvn-1.7.1-X64 (SlikSvn/1.7.1) X64
compiled Oct 26 2011, 14:18:24

C:\Users\tomas\Documents\xxx>svn update
Updating '.':
svn: E235000: In file '..\..\..\subversion\libsvn_wc\wc_db.c' line 11039:
assertion failed (base_status == svn_wc__db_status_incomplete)

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

This problem is there even if I make a fresh checkout and then update.

Tomáš Klinkovský, tkl...@iol.cz
Czech Republic

Re: svn 1.7.1 for Windows/64bit - cannot perform svn update

[Philip Martin]

Tomáš Klinkovský  writes:

> starting from svn 1.7 I cannot make "svn update" anymore on Windows 7,
> 64bit.
>
> C:\Users\tomas\Documents\xxx>svn --version
> svn, version 1.7.1-SlikSvn-1.7.1-X64 (SlikSvn/1.7.1) X64
>   compiled Oct 26 2011, 14:18:24
>
> C:\Users\tomas\Documents\xxx>svn update
> Updating '.':
> svn: E235000: In file '..\..\..\subversion\libsvn_wc\wc_db.c' line 11039:
>   assertion failed (base_status == svn_wc__db_status_incomplete)
>
> This problem is there even if I make a fresh checkout and then update.

What version of mod_dav_svn is server using?  This has been reported to
happen when the server is running the very old 1.0.8 mod_dav_svn.

-- 
Philip

Re: svn 1.7.1 for Windows/64bit - cannot perform svn update

[Tomáš Klinkovský]

Philip Martin wrote:


Tomáš Klinkovský  writes:
starting from svn 1.7 I cannot make "svn update" anymore on Windows 
7, 64bit.

C:\Users\tomas\Documents\xxx>svn --version
svn, version 1.7.1-SlikSvn-1.7.1-X64 (SlikSvn/1.7.1) X64
compiled Oct 26 2011, 14:18:24

C:\Users\tomas\Documents\xxx>svn update
Updating '.':
svn: E235000: In file '..\..\..\subversion\libsvn_wc\wc_db.c' line 11039:
assertion failed (base_status == svn_wc__db_status_incomplete)
This problem is there even if I make a fresh checkout and then update.
What version of mod_dav_svn is server using? This has been reported to 
happen when the server is running the very old 1.0.8 mod_dav_svn.


My server is also very old:

$ svn --version
svn, version 1.0.9 (r11378)
compiled Oct 14 2004, 10:04:20

But I don't access it through Apache, I have the Subversion daemon 
running and I use the "svn:" protocol.


Can I provide any other help?

Tomáš

subversion 1.7.1: can't checkout from hudson

[Matthias Bühler]

Hi,

I have a problem checking out folders from a subversion repository.

We're using the hudson continuous integration system to build projects that are 
on a subversion server. We're currently considering to upgrade to server 
version 1.7.1, but can't get it to work together with hudson.

Checkout of the repository root works fine, but as soon as I want to check out 
a subfolder (like "trunk" or "trunk/my_sub_folder"), I get an error message (in 
hudson's command line output):

>>
Checking out svn://172.16.2.156/REPO/trunk/my_sub_folder revision: 02-Nov-2011 
16:42:29 depth:infinity ignoreExternals: false
ERROR: Failed to check out svn://172.16.2.156/REPO/trunk/my_sub_folder
org.tmatesoft.svn.core.SVNException: svn: URL 
'svn://172.16.2.156/REPO/trunk/my_sub_folder' doesn't exist
<<

A look at the server log file hints that there is a problem resolving the 
subfolder path: it seems to repeat the path, resulting in 
"/trunk/my_sub_folder/trunk/my_sub_folder".

Log file from subversion server 1.7.1 (the checkout fails):
>>
2196 2011-11-03T10:34:22.184076Z 172.16.2.108 - REPO open 2 cap=(edit-pipeline 
svndiff1 absent-entries depth mergeinfo log-revprops) /trunk/my_sub_folder - -
2196 2011-11-03T10:34:22.184076Z 172.16.2.108 - REPO get-latest-rev
2196 2011-11-03T10:34:22.184076Z 172.16.2.108 - REPO get-dated-rev 
2011-11-03T10:34:22.201000Z
2196 2011-11-03T10:34:22.184076Z 172.16.2.108 - REPO get-dated-rev 
2011-11-03T10:34:22.201000Z
2196 2011-11-03T10:34:22.184076Z 172.16.2.108 - REPO check-path 
/trunk/my_sub_folder/trunk/my_sub_folder@3
2196 2011-11-03T10:34:22.184076Z 172.16.2.108 - REPO stat /trunk/my_sub_folder@3
<<

Log file from subversion server 1.6.17 (the checkout works):
>>
2704 2011-11-02T15:45:23.644467Z 172.16.2.108 - REPO open 2 cap=(edit-pipeline 
svndiff1 absent-entries depth mergeinfo log-revprops) /trunk/my_sub_folder - -
2704 2011-11-02T15:45:23.644467Z 172.16.2.108 - REPO get-latest-rev
2704 2011-11-02T15:45:23.644467Z 172.16.2.108 - REPO get-dated-rev 
2011-11-02T15:45:23.00Z
2704 2011-11-02T15:45:23.644467Z 172.16.2.108 - REPO get-dated-rev 
2011-11-02T15:45:23.00Z
2704 2011-11-02T15:45:23.644467Z 172.16.2.108 - REPO check-path 
/trunk/my_sub_folder@3
2704 2011-11-02T15:45:23.655483Z 172.16.2.108 - REPO get-dated-rev 
2011-11-02T15:45:23.00Z
2704 2011-11-02T15:45:23.666498Z 172.16.2.108 - REPO checkout-or-export 
/trunk/my_sub_folder r3 depth=infinity
2704 2011-11-02T15:45:24.845189Z 172.16.2.108 - REPO stat /@3
<<

Using the command-line client 1.7.1, I can check out the same folder from 
server 1.7.1 without any problem. Server log:
>>
2196 2011-11-03T10:45:20.731020Z 172.16.2.108 - REPO open 2 cap=(edit-pipeline 
svndiff1 absent-entries depth mergeinfo log-revprops) /trunk/my_sub_folder 
SVN/1.7.1 -
2196 2011-11-03T10:45:20.731020Z 172.16.2.108 - REPO get-latest-rev
2196 2011-11-03T10:45:20.731020Z 172.16.2.108 - REPO reparent 
/trunk/my_sub_folder
2196 2011-11-03T10:45:20.731020Z 172.16.2.108 - REPO check-path 
/trunk/my_sub_folder@3
2196 2011-11-03T10:45:20.791107Z 172.16.2.108 - REPO open 2 cap=(edit-pipeline 
svndiff1 absent-entries depth mergeinfo log-revprops) /trunk/my_sub_folder 
SVN/1.7.1 -
2196 2011-11-03T10:45:20.791107Z 172.16.2.108 - REPO get-latest-rev
2196 2011-11-03T10:45:20.791107Z 172.16.2.108 - REPO checkout-or-export 
/trunk/my_sub_folder r3
<<

In the last example, I can see that the server knows the client's version 
("SVN/1.7.1"), while in the first two examples, there is just a "-" instead of 
the version number.

Is this an issue with the client failing to report its version properly, or is 
the server supposed to work even though it doesn't know the client's version?

The server is running on Windows XP 32-bit, the client on Windows 7 64-bit. The 
Hudson client has the latest Hudson subversion plugin, which uses SVNKit 1.3.5.

Best,
Matthias.

Re: svn 1.7.1 for Windows/64bit - cannot perform svn update

[Philip Martin]

Tomáš Klinkovský  writes:

> My server is also very old:
>
> $ svn --version
> svn, version 1.0.9 (r11378)
>   compiled Oct 14 2004, 10:04:20
>
> But I don't access it through Apache, I have the Subversion daemon
> running and I use the "svn:" protocol.
>
> Can I provide any other help?

I can reproduce the error. I've raised issue 4048:

http://subversion.tigris.org/issues/show_bug.cgi?id=4048

-- 
Philip

E175002 error checking out from svgweb

[ross]

I'm trying to checkout the svgweb source and using the documented svn
command (slik windows 32 or 64 bit version):

svn checkout http://svgweb.googlecode.com/svn/trunk/ svgweb-read-only

This results in:

svn: E175002: Unable to connect to a repository at URL 'http://
svgweb.googlecode.com/svn/trunk'
svn: E175002: OPTIONS of 'http://svgweb.googlecode.com/svn/trunk':
could not connect to server (http://svgweb.googlecode.com)

I can enter the url in the browser and it connects fine.

Thanks for any help.

Re: E175002 error checking out from svgweb

[Ulrich Eckhardt]

Am 03.11.2011 14:43, schrieb ross:

I'm trying to checkout the svgweb source and using the documented svn
command (slik windows 32 or 64 bit version):

svn checkout http://svgweb.googlecode.com/svn/trunk/ svgweb-read-only


Try this:

   svn ls http://svgweb.googlecode.com/svn/trunk/

This should just list the content of the repository there, to see to 
what extent the connection works or not. This works fine from here, 
using CollabNet's 1.6.5 commandline client on MS Windows XP. What are 
your system settings?




This results in:

svn: E175002: Unable to connect to a repository at URL 'http://
svgweb.googlecode.com/svn/trunk'
svn: E175002: OPTIONS of 'http://svgweb.googlecode.com/svn/trunk':
could not connect to server (http://svgweb.googlecode.com)

I can enter the url in the browser and it connects fine.


SVN uses a few HTTP commands that not every web proxy and/or firewall 
understands, which can lead to errors. There is one thing that might fix 
this for you, and that is to use HTTPS instead of HTTP, because then the 
connection is encrypted and any proxy/firewall in between can't mess 
with the content. I checked, and the server provides HTTPS access, 
although that is not necessarily always the case.


Good luck!

Uli



**
Domino Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
**
Visit our website at http://www.dominolaser.com
**
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten 
bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen 
Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein 
sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, 
weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte 
Änderungen enthalten. Domino Laser GmbH ist für diese Folgen nicht 
verantwortlich.
**

Re: svn 1.7.1 for Windows/64bit - cannot perform svn update

[Ulrich Eckhardt]

Am 03.11.2011 12:31, schrieb Tomáš Klinkovský:

My server is also very old:

$ svn --version
svn, version 1.0.9 (r11378)
compiled Oct 14 2004, 10:04:20


Hehe, that's actually a proof that the SVN team's been doing a pretty 
good job maintaining compatibility. Seven years without a glitch, it 
seems. Thumbs up! ;)


Anyway, you might be able to work around this bug by simply upgrading 
the server. You would get a few nice features too, like the 
easier-to-manage FSFS repo format, merge tracking, optimized deltas ... 
a few years worth of features. Please take some time for this though, 
you will probably have to dump and reload your repository, and 
(IMPORTANT!) you will have to do that with the old software version. 
Make sure you have backups (but you do have a backup/recovery plan 
anyway, don't you?).


Cheers!

Uli
**
Domino Laser GmbH, Fangdieckstra�e 75a, 22547 Hamburg, Deutschland
Gesch�ftsf�hrer: Thorsten F�cking, Amtsgericht Hamburg HR B62 932
**
Visit our website at http://www.dominolaser.com
**
Diese E-Mail einschlie�lich s�mtlicher Anh�nge ist nur f�r den Adressaten 
bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen 
Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empf�nger sein 
sollten. Die E-Mail ist in diesem Fall zu l�schen und darf weder gelesen, 
weitergeleitet, ver�ffentlicht oder anderweitig benutzt werden.
E-Mails k�nnen durch Dritte gelesen werden und Viren sowie nichtautorisierte 
�nderungen enthalten. Domino Laser GmbH ist f�r diese Folgen nicht 
verantwortlich.
**

Re: E175002 error checking out from svgweb

[ross]

Thanks Uli,

https worked.

Ross

On Nov 3, 9:58 am, Ulrich Eckhardt 
wrote:
> Am 03.11.2011 14:43, schrieb ross:
>
> > I'm trying to checkout the svgweb source and using the documented svn
> > command (slik windows 32 or 64 bit version):
>
> > svn checkouthttp://svgweb.googlecode.com/svn/trunk/svgweb-read-only
>
> Try this:
>
>     svn lshttp://svgweb.googlecode.com/svn/trunk/
>
> This should just list the content of the repository there, to see to
> what extent the connection works or not. This works fine from here,
> using CollabNet's 1.6.5 commandline client on MS Windows XP. What are
> your system settings?
>
> > This results in:
>
> > svn: E175002: Unable to connect to a repository at URL 'http://
> > svgweb.googlecode.com/svn/trunk'
> > svn: E175002: OPTIONS of 'http://svgweb.googlecode.com/svn/trunk':
> > could not connect to server (http://svgweb.googlecode.com)
>
> > I can enter the url in the browser and it connects fine.
>
> SVN uses a few HTTP commands that not every web proxy and/or firewall
> understands, which can lead to errors. There is one thing that might fix
> this for you, and that is to use HTTPS instead of HTTP, because then the
> connection is encrypted and any proxy/firewall in between can't mess
> with the content. I checked, and the server provides HTTPS access,
> although that is not necessarily always the case.
>
> Good luck!
>
> Uli
>
> *** 
> ***
> Domino Laser GmbH, Fangdieckstra e 75a, 22547 Hamburg, Deutschland
> Gesch ftsf hrer: Thorsten F cking, Amtsgericht Hamburg HR B62 932
> *** 
> ***
> Visit our website athttp://www.dominolaser.com
> *** 
> ***
> Diese E-Mail einschlie lich s mtlicher Anh nge ist nur f r den Adressaten 
> bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen 
> Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empf nger sein 
> sollten. Die E-Mail ist in diesem Fall zu l schen und darf weder gelesen, 
> weitergeleitet, ver ffentlicht oder anderweitig benutzt werden.
> E-Mails k nnen durch Dritte gelesen werden und Viren sowie nichtautorisierte 
> nderungen enthalten. Domino Laser GmbH ist f r diese Folgen nicht 
> verantwortlich.
> *** 
> ***

Re: E175002 error checking out from svgweb

[ross]

Thanks Uli,

https worked.

Ross

On Nov 3, 9:58 am, Ulrich Eckhardt 
wrote:
> Am 03.11.2011 14:43, schrieb ross:
>
> > I'm trying to checkout the svgweb source and using the documented svn
> > command (slik windows 32 or 64 bit version):
>
> > svn checkouthttp://svgweb.googlecode.com/svn/trunk/svgweb-read-only
>
> Try this:
>
>     svn lshttp://svgweb.googlecode.com/svn/trunk/
>
> This should just list the content of the repository there, to see to
> what extent the connection works or not. This works fine from here,
> using CollabNet's 1.6.5 commandline client on MS Windows XP. What are
> your system settings?
>
> > This results in:
>
> > svn: E175002: Unable to connect to a repository at URL 'http://
> > svgweb.googlecode.com/svn/trunk'
> > svn: E175002: OPTIONS of 'http://svgweb.googlecode.com/svn/trunk':
> > could not connect to server (http://svgweb.googlecode.com)
>
> > I can enter the url in the browser and it connects fine.
>
> SVN uses a few HTTP commands that not every web proxy and/or firewall
> understands, which can lead to errors. There is one thing that might fix
> this for you, and that is to use HTTPS instead of HTTP, because then the
> connection is encrypted and any proxy/firewall in between can't mess
> with the content. I checked, and the server provides HTTPS access,
> although that is not necessarily always the case.
>
> Good luck!
>
> Uli
>
> *** 
> ***
> Domino Laser GmbH, Fangdieckstra e 75a, 22547 Hamburg, Deutschland
> Gesch ftsf hrer: Thorsten F cking, Amtsgericht Hamburg HR B62 932
> *** 
> ***
> Visit our website athttp://www.dominolaser.com
> *** 
> ***
> Diese E-Mail einschlie lich s mtlicher Anh nge ist nur f r den Adressaten 
> bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen 
> Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empf nger sein 
> sollten. Die E-Mail ist in diesem Fall zu l schen und darf weder gelesen, 
> weitergeleitet, ver ffentlicht oder anderweitig benutzt werden.
> E-Mails k nnen durch Dritte gelesen werden und Viren sowie nichtautorisierte 
> nderungen enthalten. Domino Laser GmbH ist f r diese Folgen nicht 
> verantwortlich.
> *** 
> ***

RE: Error when updating

[Wabe W]

> >> I assume you are using some sort of server.  Which version of Subversion
> >> is the server running?  
> 
> > It is 1.0.8 (2004)
> 
> That's old (very old) and unsupported.  
I will tell my professor :-)

> The client should still work but
> I haven't built or used 1.0.x for years.
So, we just have to update the server and see if the problem is solved?

> >>Is it a googlecode server?  Are you using serf or neon?
> 
> > I sent the person that runs the server an e-mail regarding these questions.
> > It is a Linux server, that I know.
> 
> It won't be a googlecode server.  serf/neon is a client question.
We use the standard: neon
> 
> -- 
> Philip
-Wabe
  

Re: Error when updating

[Philip Martin]

Wabe W  writes:

> So, we just have to update the server and see if the problem is solved?

It's issue 4048, it may get fixed in a 1.7.x release:
http://subversion.tigris.org/issues/show_bug.cgi?id=4048

-- 
Philip

post-commit hook problems with SMTP

[David Weintraub]

I've written a Perl post-commit hook that emails out via SMTP. I was
getting the following error when I try to do a commit:

Sendingsubversion/README
Transmitting file data .svn: Commit failed (details follow):
svn: MERGE of '/mfxcm/trunk/subversion': 200 OK (http://source)

The commit actually had worked, but the revision of my working copy
wasn't updated until I did a "svn up":

$ svn commit -m"Finding what's causing commit errors. I think it's
the post-commit script"
Sendingsubversion/README
Transmitting file data .svn: Commit failed (details follow):
svn: MERGE of '/mfxcm/trunk/subversion': 200 OK (http://source)
david@DaveBook.local:~/workspace/svn-cm-trunk/subversion
$ svn up
GREADME
Updated to revision 94.

I've played around with my post-commit script, and everything is find
until I do:

my $smtp = Net::SMTP->new(
Host  => $self->SmtpHost,
Debug => $main::debugLevel,

Then, I get the MERGE error again. If I take out the SMTP portion of
the script, everything works just fine. If I put in starting SMTP, it
fails.

I know the script actually works because I print out the command to
execute my post-commit hook, and I can run it from the command line
without any problems. It only gets that MERGE error if run as a
post-commit hook.

What exactly does that MERGE error mean, and why do I get it when
Subversion runs the post-commit hook vs. when I run the same thing
from the command line?

-- 
David Weintraub
qazw...@gmail.com

Re: tortoise 1.7 - error on repository manipulation

[Erwane Breton]

I reopen this topic because the problem is not solved.

All is explained here : http://www.redmine.org/issues/9517

The problem come from mod_passenger and routing.

Question is : how to bypass rails routing for /svn/ url


rails production log

ActionController::RoutingError (No route matches "/svn/site/!svn/me" 
with {:method=>:post}):
  passenger (3.0.9) lib/phusion_passenger/rack/request_handler.rb:96:in 
`process_request'



Le 27/10/2011 16:19, Erwane Breton a écrit :

Hi,

history :
I haved a FreeBSD server (8.0-STABLE) with subversion-1.6.17_2 port.
Acces to repository is configured thrue apache 2.2 + mod_dav + dav_svn.
Of course, all works fine :)

I've got a new server on FreeBSD 8.2-STABLE with subversion-1.7.1, 
apache, mod_dav & dav_svn.

All works fine ... in checkout and update.

For migration, i've make first a rsync only, when i saw the error (cf 
bottom) i've made that more cleanly with svnadmin dump and svnadmin load.

In both cases, result is the same.

Now the error ^^

On my client (windows 7 x64 tortoise SVN), i CAN commit with Tortoise 
1.6.15 on my laptop but i CAN'T commit (or rename or delete) on my 
other computer with tortoise 1.7.1.22161


The error is always the same


Commit
Commit failed (details follow):
'/svn/site/*!svn/me*' path not found


My repository is https://xyz.coda-cola.net/svn/site/trunk

I've tried svnadmin upgrade, exactly the same.

apache debug error logs (without openSSL informations)

[Thu Oct 27 14:58:57 2011] [info] Connection: Client IP: 
82.226.xxx.xxx, Protocol: SSLv3, Cipher: DHE-RSA-AES256-SHA (256/256 
bits)
[Thu Oct 27 14:58:57 2011] [info] Initial (No.1) HTTPS request 
received for child 0 (server xyz.coda-cola.net:443)
[Thu Oct 27 14:58:57 2011] [debug] 
subversion/mod_authz_svn/mod_authz_svn.c(193): [client 
82.226.xxx.xxx] Path to authz file is 
/exports/svn/xyz/authorizations.conf
[Thu Oct 27 14:58:57 2011] [debug] mod_deflate.c(615): [client 
82.226.xxx.xxx] Zlib: Compressed 401 to 272 : URL /svn/site/trunk
[Thu Oct 27 14:58:57 2011] [info] Subsequent (No.2) HTTPS request 
received for child 0 (server xyz.coda-cola.net:443)
[Thu Oct 27 14:58:57 2011] [debug] 
subversion/mod_authz_svn/mod_authz_svn.c(193): [client 
82.226.xxx.xxx] Path to authz file is 
/exports/svn/xyz/authorizations.conf
[Thu Oct 27 14:58:57 2011] [info] [client 82.226.203.234] Access 
granted: 'erwane' OPTIONS site:/trunk
[Thu Oct 27 14:58:57 2011] [debug] mod_deflate.c(615): [client 
82.226.xxx.xxx] Zlib: Compressed 188 to 126 : URL /svn/site/trunk
[Thu Oct 27 14:58:57 2011] [info] Subsequent (No.3) HTTPS request 
received for child 0 (server xyz.coda-cola.net:443)
[Thu Oct 27 14:58:57 2011] [debug] 
subversion/mod_authz_svn/mod_authz_svn.c(193): [client 
82.226.xxx.xxx] Path to authz file is 
/exports/svn/xyz/authorizations.conf
[Thu Oct 27 14:58:57 2011] [info] [client 82.226.203.234] Access 
granted: 'erwane' POST site:
[Thu Oct 27 14:59:00 2011] [debug] mod_deflate.c(615): [client 
82.226.xxx.xxx] Zlib: Compressed 484 to 354 : URL /svn/site/*!svn/me*


After googled, i've found only "no space left on disk" but my ZFS 
volume is completely not full.


just tried without SSL, it's the same.

really dunno where to search now :(

Thanks for help

--
Erwane Breton
  Phea
Tel: 09 51 20 23 23
Mob: 06 76 46 54 61


--
Erwane Breton
 Phea
Tel: 09 51 20 23 23
Mob: 06 76 46 54 61

GnomeKeyring: not entering passwords

[rupert.thurner]

while looking for a possibility to help a user of subversion so he
does not need to type the server password all the time, i got hinted
to GnomeKeyring and seahorse. subversion offers to be compile with --
with-gnome-keyring option.

what we finally want to have is a one time prompt on the command line
(no gui available) after booting the operating system, or logging into
the user or starting some daemon to log into the keyring, and never
again. the goal is to have a continuous integration environment that
does not expose the passwords (easily) to the users of the server.

as i understood there are three pieces of software:
* GnomeKeyring daemon, allowing an application to store and retrieve
passwords
* GnomeKeyring manager, deprecated by
* seahorse, a gui application which allows to manage keys

would this be realistic using the GnomeKeyring daemon? i want to
include it for the http://opencsw.org subversion solaris build, and
wonder what additionally needs to be configured on the client side so
this works seamlessly.

rupert

Re: GnomeKeyring: not entering passwords

[Mark Phippard]

On Thu, Nov 3, 2011 at 2:38 PM, rupert.thurner wrote:

> while looking for a possibility to help a user of subversion so he
> does not need to type the server password all the time, i got hinted
> to GnomeKeyring and seahorse. subversion offers to be compile with --
> with-gnome-keyring option.
>

I had never heard of seahorse.  Looking at it, it seems to me like it is a
GUI for using GNOME keyring to manage things like your SSH keys etc.  I do
not think that is what you need.  GNOME keyring already provides a GUI for
managing your keyring and this is tied to your login session.  What we did
for our CollabNet binaries was write a small command line tool that uses
the GNOME keyring API but gives you a simple command line interface.  I do
not know why GNOME does not provide one.  I would be happy to share the
source code if you want it.

With this tool you can use the command line tool to create a keyring as
well as unlock it.  The latter is what you would want to do when you login
(after starting the keyring-daemon).

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

Re: tortoise 1.7 - error on repository manipulation

[Erwane Breton]

And solution (sorry list :))

add "PassengerEnabled Off" in  apache section.


http://www.redmine.org/issues/9517#note-1

Hope this time all work fine for a lgg time ;)



Le 03/11/2011 19:24, Erwane Breton a écrit :

I reopen this topic because the problem is not solved.

All is explained here : http://www.redmine.org/issues/9517

The problem come from mod_passenger and routing.

Question is : how to bypass rails routing for /svn/ url


rails production log

ActionController::RoutingError (No route matches "/svn/site/!svn/me" 
with {:method=>:post}):
  passenger (3.0.9) 
lib/phusion_passenger/rack/request_handler.rb:96:in `process_request'



Le 27/10/2011 16:19, Erwane Breton a écrit :

Hi,

history :
I haved a FreeBSD server (8.0-STABLE) with subversion-1.6.17_2 port.
Acces to repository is configured thrue apache 2.2 + mod_dav + dav_svn.
Of course, all works fine :)

I've got a new server on FreeBSD 8.2-STABLE with subversion-1.7.1, 
apache, mod_dav & dav_svn.

All works fine ... in checkout and update.

For migration, i've make first a rsync only, when i saw the error (cf 
bottom) i've made that more cleanly with svnadmin dump and svnadmin load.

In both cases, result is the same.

Now the error ^^

On my client (windows 7 x64 tortoise SVN), i CAN commit with Tortoise 
1.6.15 on my laptop but i CAN'T commit (or rename or delete) on my 
other computer with tortoise 1.7.1.22161


The error is always the same


Commit
Commit failed (details follow):
'/svn/site/*!svn/me*' path not found


My repository is https://xyz.coda-cola.net/svn/site/trunk

I've tried svnadmin upgrade, exactly the same.

apache debug error logs (without openSSL informations)

[Thu Oct 27 14:58:57 2011] [info] Connection: Client IP: 
82.226.xxx.xxx, Protocol: SSLv3, Cipher: DHE-RSA-AES256-SHA (256/256 
bits)
[Thu Oct 27 14:58:57 2011] [info] Initial (No.1) HTTPS request 
received for child 0 (server xyz.coda-cola.net:443)
[Thu Oct 27 14:58:57 2011] [debug] 
subversion/mod_authz_svn/mod_authz_svn.c(193): [client 
82.226.xxx.xxx] Path to authz file is 
/exports/svn/xyz/authorizations.conf
[Thu Oct 27 14:58:57 2011] [debug] mod_deflate.c(615): [client 
82.226.xxx.xxx] Zlib: Compressed 401 to 272 : URL /svn/site/trunk
[Thu Oct 27 14:58:57 2011] [info] Subsequent (No.2) HTTPS request 
received for child 0 (server xyz.coda-cola.net:443)
[Thu Oct 27 14:58:57 2011] [debug] 
subversion/mod_authz_svn/mod_authz_svn.c(193): [client 
82.226.xxx.xxx] Path to authz file is 
/exports/svn/xyz/authorizations.conf
[Thu Oct 27 14:58:57 2011] [info] [client 82.226.203.234] Access 
granted: 'erwane' OPTIONS site:/trunk
[Thu Oct 27 14:58:57 2011] [debug] mod_deflate.c(615): [client 
82.226.xxx.xxx] Zlib: Compressed 188 to 126 : URL /svn/site/trunk
[Thu Oct 27 14:58:57 2011] [info] Subsequent (No.3) HTTPS request 
received for child 0 (server xyz.coda-cola.net:443)
[Thu Oct 27 14:58:57 2011] [debug] 
subversion/mod_authz_svn/mod_authz_svn.c(193): [client 
82.226.xxx.xxx] Path to authz file is 
/exports/svn/xyz/authorizations.conf
[Thu Oct 27 14:58:57 2011] [info] [client 82.226.203.234] Access 
granted: 'erwane' POST site:
[Thu Oct 27 14:59:00 2011] [debug] mod_deflate.c(615): [client 
82.226.xxx.xxx] Zlib: Compressed 484 to 354 : URL /svn/site/*!svn/me*


After googled, i've found only "no space left on disk" but my ZFS 
volume is completely not full.


just tried without SSL, it's the same.

really dunno where to search now :(

Thanks for help

--
Erwane Breton
  Phea
Tel: 09 51 20 23 23
Mob: 06 76 46 54 61


--
Erwane Breton
  Phea
Tel: 09 51 20 23 23
Mob: 06 76 46 54 61


--
Erwane Breton
 Phea
Tel: 09 51 20 23 23
Mob: 06 76 46 54 61

Re: GnomeKeyring: not entering passwords

[Geoff Hoffman]

On Thu, Nov 3, 2011 at 11:54 AM, Mark Phippard  wrote:

> On Thu, Nov 3, 2011 at 2:38 PM, rupert.thurner 
> wrote:
>
>> while looking for a possibility to help a user of subversion so he
>> does not need to type the server password all the time, i got hinted
>> to GnomeKeyring and seahorse. subversion offers to be compile with --
>> with-gnome-keyring option.
>>
>
> I had never heard of seahorse.  Looking at it, it seems to me like it is a
> GUI for using GNOME keyring to manage things like your SSH keys etc.  I do
> not think that is what you need.  GNOME keyring already provides a GUI for
> managing your keyring and this is tied to your login session.  What we did
> for our CollabNet binaries was write a small command line tool that uses
> the GNOME keyring API but gives you a simple command line interface.  I do
> not know why GNOME does not provide one.  I would be happy to share the
> source code if you want it.
>
> With this tool you can use the command line tool to create a keyring as
> well as unlock it.  The latter is what you would want to do when you login
> (after starting the keyring-daemon).
>
>

There have been several discussions about this in the past. If you haven't
already, definitely search the archives.
http://svn.haxx.se/users/

Re: Message: Access to '/repos/asf/!svn/me' forbidden

[Daniel Shahaf]

Use https instead of http

Wojcik, Robert C. wrote on Wed, Nov 02, 2011 at 15:26:36 -0400:
> Hi all:
> 
> Why would this error message  be generated when accessing the apache 
> subversion repository using the "Update to revision" command from the repo 
> window for the Apache ActiveMQ trunk?
> 
> Best Regards,
> Robert C. Wojcik, Ph.D.
>Enterprise Knowledge Systems Group (AISD-VES)
> 
>Johns Hopkins University
>Applied Physics Laboratory
>11100 Johns Hopkins Road
>M/S 24-E229
>Laurel, MD 20723-6099
> 
>Email: robert.woj...@jhuapl.edu
>Blackberry: (410) 294-9651
>Phone: (240) 228-9168 / Washington
>(443) 778-9168 / Baltimore
>FAX:(240) 228-2551 / Washington
>(443) 778-2551 / Baltimore
> 

Re: post-commit hook problems with SMTP

[Daniel Shahaf]

David Weintraub wrote on Thu, Nov 03, 2011 at 12:46:52 -0400:
> I've written a Perl post-commit hook that emails out via SMTP. I was
> getting the following error when I try to do a commit:
> 
> Sendingsubversion/README
> Transmitting file data .svn: Commit failed (details follow):
> svn: MERGE of '/mfxcm/trunk/subversion': 200 OK (http://source)
> 
> The commit actually had worked, but the revision of my working copy
> wasn't updated until I did a "svn up":
> 
> $ svn commit -m"Finding what's causing commit errors. I think it's
> the post-commit script"
> Sendingsubversion/README
> Transmitting file data .svn: Commit failed (details follow):
> svn: MERGE of '/mfxcm/trunk/subversion': 200 OK (http://source)
> david@DaveBook.local:~/workspace/svn-cm-trunk/subversion
> $ svn up
> GREADME
> Updated to revision 94.
> 
> I've played around with my post-commit script, and everything is find
> until I do:
> 
> my $smtp = Net::SMTP->new(
> Host  => $self->SmtpHost,
> Debug => $main::debugLevel,
> 
> Then, I get the MERGE error again. If I take out the SMTP portion of
> the script, everything works just fine. If I put in starting SMTP, it
> fails.
> 
> I know the script actually works because I print out the command to
> execute my post-commit hook, and I can run it from the command line
> without any problems. It only gets that MERGE error if run as a
> post-commit hook.
> 
> What exactly does that MERGE error mean, and why do I get it when
> Subversion runs the post-commit hook vs. when I run the same thing
> from the command line?

I think MERGE is the DAV command that corresponds to "Commit this
transaction (i.e., promote it to a revision)".

Anyway: when svn runs the hook, it only looks at its exit code, stderr,
and stdout.  So, check how these three change with/without the Net::SMTP
invocation.

You probably know that there's a FAQ entry recommending the proper way
to test a hook: as the server's user, with an empty environment, etc.

> 
> -- 
> David Weintraub
> qazw...@gmail.com

Re: subversion 1.7.1: can't checkout from hudson

[Daniel Shahaf]

Matthias Bühler wrote on Thu, Nov 03, 2011 at 12:04:04 +:
> Hi,
> 
> I have a problem checking out folders from a subversion repository.
> 
> We're using the hudson continuous integration system to build projects that 
> are on a subversion server. We're currently considering to upgrade to server 
> version 1.7.1, but can't get it to work together with hudson.
> 
> Checkout of the repository root works fine, but as soon as I want to check 
> out a subfolder (like "trunk" or "trunk/my_sub_folder"), I get an error 
> message (in hudson's command line output):
> 
> >>
> Checking out svn://172.16.2.156/REPO/trunk/my_sub_folder revision: 
> 02-Nov-2011 16:42:29 depth:infinity ignoreExternals: false
> ERROR: Failed to check out svn://172.16.2.156/REPO/trunk/my_sub_folder
> org.tmatesoft.svn.core.SVNException: svn: URL 
> 'svn://172.16.2.156/REPO/trunk/my_sub_folder' doesn't exist
> <<
> 
> A look at the server log file hints that there is a problem resolving the 
> subfolder path: it seems to repeat the path, resulting in 
> "/trunk/my_sub_folder/trunk/my_sub_folder".
> 
> Log file from subversion server 1.7.1 (the checkout fails):
> >>
> 2196 2011-11-03T10:34:22.184076Z 172.16.2.108 - REPO open 2 
> cap=(edit-pipeline svndiff1 absent-entries depth mergeinfo log-revprops) 
> /trunk/my_sub_folder - -
> 2196 2011-11-03T10:34:22.184076Z 172.16.2.108 - REPO get-latest-rev
> 2196 2011-11-03T10:34:22.184076Z 172.16.2.108 - REPO get-dated-rev 
> 2011-11-03T10:34:22.201000Z
> 2196 2011-11-03T10:34:22.184076Z 172.16.2.108 - REPO get-dated-rev 
> 2011-11-03T10:34:22.201000Z
> 2196 2011-11-03T10:34:22.184076Z 172.16.2.108 - REPO check-path 
> /trunk/my_sub_folder/trunk/my_sub_folder@3
> 2196 2011-11-03T10:34:22.184076Z 172.16.2.108 - REPO stat 
> /trunk/my_sub_folder@3
> <<
> 
> Log file from subversion server 1.6.17 (the checkout works):
> >>
> 2704 2011-11-02T15:45:23.644467Z 172.16.2.108 - REPO open 2 
> cap=(edit-pipeline svndiff1 absent-entries depth mergeinfo log-revprops) 
> /trunk/my_sub_folder - -
> 2704 2011-11-02T15:45:23.644467Z 172.16.2.108 - REPO get-latest-rev
> 2704 2011-11-02T15:45:23.644467Z 172.16.2.108 - REPO get-dated-rev 
> 2011-11-02T15:45:23.00Z
> 2704 2011-11-02T15:45:23.644467Z 172.16.2.108 - REPO get-dated-rev 
> 2011-11-02T15:45:23.00Z
> 2704 2011-11-02T15:45:23.644467Z 172.16.2.108 - REPO check-path 
> /trunk/my_sub_folder@3

This is where this log differs from the previous one.  Perhaps you could
get a wire trace (wireshark, tcpdump, etc) and diff the protocol traces
until this point to see what leads to the divergence?

> 2704 2011-11-02T15:45:23.655483Z 172.16.2.108 - REPO get-dated-rev 
> 2011-11-02T15:45:23.00Z
> 2704 2011-11-02T15:45:23.666498Z 172.16.2.108 - REPO checkout-or-export 
> /trunk/my_sub_folder r3 depth=infinity
> 2704 2011-11-02T15:45:24.845189Z 172.16.2.108 - REPO stat /@3
> <<
> 
> Using the command-line client 1.7.1, I can check out the same folder from 
> server 1.7.1 without any problem. Server log:
> >>
> 2196 2011-11-03T10:45:20.731020Z 172.16.2.108 - REPO open
> 2 cap=(edit-pipeline svndiff1 absent-entries depth mergeinfo
> log-revprops) /trunk/my_sub_folder SVN/1.7.1 -

That's odd.  With 1.7 client and server you should see the
atomic-revprops capability somewhere.

> 2196 2011-11-03T10:45:20.731020Z 172.16.2.108 - REPO get-latest-rev
> 2196 2011-11-03T10:45:20.731020Z 172.16.2.108 - REPO reparent 
> /trunk/my_sub_folder
> 2196 2011-11-03T10:45:20.731020Z 172.16.2.108 - REPO check-path 
> /trunk/my_sub_folder@3

Hmm.

> 2196 2011-11-03T10:45:20.791107Z 172.16.2.108 - REPO open
> 2 cap=(edit-pipeline svndiff1 absent-entries depth mergeinfo
> log-revprops) /trunk/my_sub_folder SVN/1.7.1 -
> 2196 2011-11-03T10:45:20.791107Z 172.16.2.108 - REPO get-latest-rev
> 2196 2011-11-03T10:45:20.791107Z 172.16.2.108 - REPO checkout-or-export 
> /trunk/my_sub_folder r3
> <<
> 
> In the last example, I can see that the server knows the client's
> version ("SVN/1.7.1"), while in the first two examples, there is just
> a "-" instead of the version number.
> 
> Is this an issue with the client failing to report its version
> properly, or is the server supposed to work even though it doesn't
> know the client's version?
> 

The client can optionally report its version to the server.

> The server is running on Windows XP 32-bit, the client on Windows
> 7 64-bit. The Hudson client has the latest Hudson subversion plugin,
> which uses SVNKit 1.3.5.

Note that SVNKit doesn't use the official C libraries at all.  If the
problem turns out to be client side, you'll have to take it up with
them, not us.

Enforce File Name with Naming Convention

[michael mac]

Hi,

I've searched through the archives and wasn't able to find an answer so I'm
posting in hope that someone can help. There's a requirement to enforce
file naming convention under particular svn paths. The convention name will
be "numeric dot number" (1.1). I have looked into svnperm.py and
commit-access-control.pl as a pre-commit hook option, but they don't seem
to have the ability to fill this requirement.

Requirement: There are multiple projects under repo A and each project has
it's own submissions folder (/repoA/project1/submissions). I want to be
able to enforce a naming convention in the pre-commit hook to only allow
folders with the name of "numeric dot numeric" under the submission folder
(/repoA/project1/submissions/1.1). No other naming convention is allowed.
And out of many projects, I only need this for a few projects at the
moment, but this may change. But I won't be applying this to all projects
under repo A, only a selective few.

Thanks in advance,

Michael

Re: Enforce File Name with Naming Convention

[Ryan Schmidt]

On Nov 3, 2011, at 19:48, michael mac wrote:

> I've searched through the archives and wasn't able to find an answer so I'm 
> posting in hope that someone can help. There's a requirement to enforce file 
> naming convention under particular svn paths. The convention name will be 
> "numeric dot number" (1.1). I have looked into svnperm.py and 
> commit-access-control.pl as a pre-commit hook option, but they don't seem to 
> have the ability to fill this requirement. 
> 
> Requirement: There are multiple projects under repo A and each project has 
> it's own submissions folder (/repoA/project1/submissions). I want to be able 
> to enforce a naming convention in the pre-commit hook to only allow folders 
> with the name of "numeric dot numeric" under the submission folder  
> (/repoA/project1/submissions/1.1). No other naming convention is allowed. And 
> out of many projects, I only need this for a few projects at the moment, but 
> this may change. But I won't be applying this to all projects under repo A, 
> only a selective few.

Write a pre-commit hook script that enforces this requirement.

Error during large checkouts with serf

[James Chan]

I have some very very large checkouts. > 50GB.

with neon the checkout works fine.

with serf I get.

svn: E730053: Error retrieving REPORT (730053): An established connection
was ab
orted by the software in your host machine.

This happens with both tortoiseSVN and the command line clients.

It happens when about 20GB's of data has been downloaded.

Anyone else see this?

--
James