RE: Python 2.6 bindings

[Cooke, Mark]

Hello,

> -Original Message-
> From: Alina Frey [mailto:af...@modusoperandi.com] 
> Sent: 27 January 2011 20:14
> To: users@subversion.apache.org
> Subject: Python 2.6 bindings
> 
> I am new to Subversion. Need to use Subversion with Trac. 
> Trac requires Python, therefore I need the Python bindings, 
> so I downloaded svn-win32-1.6.13_py.zip 
>  . 
> Would you please let me know what do I need to do after I 
> extract all the files from svn-win32-1.6.13_py.zip 
>  ?
> 
> Thank you,
> 
> Alina.
> 
As you mention alagazam, I will assume you are on windows...  However,
why are you installing 1.6.13 when 1.6.15 is available?

I asked almost this question a while back (on the Trac Users mailing
list) and did not really get an answer.  However, some searching of both
svn and Trac documentation lead me to write the following notes for
myself which is what I now follow.  Let me know if this works for you
too (obviously you can ignore the first two steps)...

Upgrading the Python Bindings for Subversion:
=

Just to complete this thread with the hope of being useful to someone
else,
this is what I did to install the latest svn from Algazam onto windoze:

~ stopped the apache service

~ uninstalled all previous subversion instances (tidying up really)

~ ran the Algazam windows .msi installer

~ copied the latest mod_*.so files from the install location to the 
  apache modules directory (overwriting the old ones)

~ deleted the old svn and libsvn directories from
C:\Python26\Lib\site-packages

~ opened the python bindings .zip and copied the two directories
  to site-packages

~ copied all libsvn\_*.dll files to _*.pyd [1]

~ restarted the server and crossed fingers...

[1] I found this recommended in the t.e.o wiki at TracSubversion...
http://trac.edgewall.org/wiki/TracSubversion#forPython2.6

In other words, it was fine to just delete the old files from
site_packages
and copy the new ones in there, with just a bit of fiddling about!

~ mark c

P.S. please consider using plain text email for this list...

Re: global SSL trust CA

[Jehan PROCACCIA]

Le 27/01/2011 20:04, Stefan Sperling a écrit :

On Thu, Jan 27, 2011 at 06:52:02PM +0100, Jehan PROCACCIA wrote:

hello,

since I configure my svn server in https , any time I do a co or ci
I get the server certificate presented and pompting me to accept it
temporarly or reject it.
To prevent that I set in  ~/.subversion/servers
[global]
ssl-authority-files = /etc/pki/tls/certs/cachain.pem

Now, is there a way to allow that CA file globally to all users on
the machine, because I don't want to ask each and every of my 200
students to edit their ~/.subversion/servers .
isn't there a global configuration file for that ?

Yes, there is: /etc/subversion/servers

Stefan
thanks , copying my  ~/.subversion/servers to /etc/subversion/servers 
seems to do the job .
I run an rpm base distrib ... should'nt that file be there by default ? 
or I missed to install a package ?


# rpm -qa | grep subversion
subversion-javahl-1.6.13-1.fc13.i686
subversion-1.6.13-1.fc13.i686
subversion-libs-1.6.13-1.fc13.i686

Re: Checkout really slow in Windows with lots of files in one directory

[Paul Holden]

On 27 Jan 2011 08:23, "Neil Bird"  wrote:
>
>  The thread petered out with someone trying the 1.7
svn_io_open_unique_file impl. in a 1.6 build, but I can't see any feedback
from that (so I'm afraid I'm going to cheekily Cc: the guys who posted that
that was being tried!).
>

Hi,

Yes - that was me. We ended up finding a lame but usable workaround so I'm
afraid we never got around to trying out the patch.

FWIW, we just wrote a script which ran:

svn up a*
svn up b*
...
svn up

Like I say, it's pretty lame, but it neatly mitigated the N^2 behaviour we
were seeing.

Regards,
Paul

sparse working directories and externals

[Dave Andreas]

I've encountered a few anomalies regarding the sparse workaareas and externals. 
 I can construct a sparse workarea using either a top down approach or a 
bottoms up approach as shown in the following examples

Top down:

$ svn co -depth immediates  modules
A modules
A modules/module1
A modules/module2
$ svn update -set-depth immediates modules/*
A modules/module1/subdir1
A modules/module1/subdir2
A modules/module2/subdir1
A modules/module2/subdir2
$svn update -set-depth infinity modules/*/subdir1
A modules/module1/subdir1/file1
A modules/module2/subdir1/file3

Bottoms up:

$svn co  modules
A modules
A modules/module1
A modules/module1/subdir1
A modules/module1/subdir1/file1
A modules/module2/subdir2
A modules/module1/subdir2/file2
A modules/module2
A moduels/module2/subdir1
A modules/module2/subdir1/file3
A modules/module2/subdir2
A modules/module2/subdir2/file4
A modules/external1/subdir1
A modules/external1/subdir1/file5
A modules/external1/subdir2/
A modules/external1/subdir2/file6
$svn update -set-depth empty modules/*/subdir2
D modules/module1/subdir2/file2
D modules/module2/subdir2/file4
D modules/external1/subdir2/file6

If it weren't for the external, the result is the same.  Unfortunately the 
initial checkout of an external appears to be an all or nothing scenario 
requiring a depth of infinity.

The disadvantage of a bottoms up approach is that I'm checking out everything 
from the repository into the workarea and them pruning it back.  In my actual 
case, I'm dealing with 10's of thousands of file and this process can take 
nearly 3 hours.

The ideal solution would be a top down approach that handled externals 
identically to modules from the local repository.

Any suggestions?

Dave Andreas












This message (including any attachments) is intended only for the use of the 
individual or entity to which it is addressed and may contain information that 
is non-public, proprietary, privileged, confidential, and exempt from 
disclosure under applicable law or may constitute as attorney work product.  If 
you are not the intended recipient, you are hereby notified that any use, 
dissemination, distribution, or copying of this communication is strictly 
prohibited. If you have received this communication in error, notify us 
immediately by telephone and (i) destroy this message if a facsimile or (ii) 
delete this message immediately if this is an electronic communication.  

Thank you.

RE: Python 2.6 bindings

[Alina Frey]

Yes, I am on Windows.
I installed Apache Subversion (Setup-Subversion-1.6.15.msi). No previous
versions installed.
You mentioned that I need to stop apache server. How do I know if it's
running?
You mentioned that we need to copy mod_*.so files to the apache modules
folder. Was I supposed to have an apache folder anywhere (where?). Was I
supposed to install apache separately? Or it's included in Python somewhere?
I copied svn and libsvn folders to C:\Python26\Lib\site-packages.
What did you mean by "copied all libsvn\_*.dll files to _*.pyd"? Move all
the dll files from under libsvn to one folder up and modify the extension to
pyd?

I appreciate any input. Thank you,

- Alina.

-Original Message-
From: Cooke, Mark [mailto:mark.co...@siemens.com] 
Sent: Friday, January 28, 2011 3:05 AM
To: Alina Frey
Cc: users@subversion.apache.org
Subject: RE: Python 2.6 bindings

Hello,

> -Original Message-
> From: Alina Frey [mailto:af...@modusoperandi.com] 
> Sent: 27 January 2011 20:14
> To: users@subversion.apache.org
> Subject: Python 2.6 bindings
> 
> I am new to Subversion. Need to use Subversion with Trac. 
> Trac requires Python, therefore I need the Python bindings, 
> so I downloaded svn-win32-1.6.13_py.zip 
>  . 
> Would you please let me know what do I need to do after I 
> extract all the files from svn-win32-1.6.13_py.zip 
>  ?
> 
> Thank you,
> 
> Alina.
> 
As you mention alagazam, I will assume you are on windows...  However,
why are you installing 1.6.13 when 1.6.15 is available?

I asked almost this question a while back (on the Trac Users mailing
list) and did not really get an answer.  However, some searching of both
svn and Trac documentation lead me to write the following notes for
myself which is what I now follow.  Let me know if this works for you
too (obviously you can ignore the first two steps)...

Upgrading the Python Bindings for Subversion:
=

Just to complete this thread with the hope of being useful to someone
else,
this is what I did to install the latest svn from Algazam onto windoze:

~ stopped the apache service

~ uninstalled all previous subversion instances (tidying up really)

~ ran the Algazam windows .msi installer

~ copied the latest mod_*.so files from the install location to the 
  apache modules directory (overwriting the old ones)

~ deleted the old svn and libsvn directories from
C:\Python26\Lib\site-packages

~ opened the python bindings .zip and copied the two directories
  to site-packages

~ copied all libsvn\_*.dll files to _*.pyd [1]

~ restarted the server and crossed fingers...

[1] I found this recommended in the t.e.o wiki at TracSubversion...
http://trac.edgewall.org/wiki/TracSubversion#forPython2.6

In other words, it was fine to just delete the old files from
site_packages
and copy the new ones in there, with just a bit of fiddling about!

~ mark c

P.S. please consider using plain text email for this list...


smime.p7s
Description: S/MIME cryptographic signature

Re: Python 2.6 bindings

[Daniel Shahaf]

Alina Frey wrote on Fri, Jan 28, 2011 at 14:05:19 -0500:
> Yes, I am on Windows.
> I installed Apache Subversion (Setup-Subversion-1.6.15.msi). No previous
> versions installed.

Oh, and just to clarify: "Apache Subversion" includes mod_dav_svn, but
does /not/ include the Apache HTTP Server (httpd) --- if you want it,
you need to download it separately.

I'll be happy to add a statement to that effect to our web site if needed.

(there's already the issue of "the Apache Subversion repository", which
is an ambiguous phrase...)

> You mentioned that I need to stop apache server. How do I know if it's
> running?

netstat -an

> You mentioned that we need to copy mod_*.so files to the apache modules
> folder. Was I supposed to have an apache folder anywhere (where?). Was I
> supposed to install apache separately? Or it's included in Python somewhere?

mod_dav_svn and httpd aren't included in the python bindings.