Re: svn update or rsync - which is best to update live files

2011-02-27 Thread Campbell Allan

On Sunday 27 Feb 2011, Chris Albertson wrote:
> OK,   There is one way that works.  I'd suggest using it.
>
> Most server OSes now have some way to make a virtual hoist.  Solaris
> has zones, Linux has xen and there is VMware.  The idea is that you
> build the new updated web site on a new virtual host.  and then you
> test it.  Once you like the tst results you swap IP addresses. You
> don't really want to go live with changes that are untested.  The IP
> address is "atomic" in that the entire site goes live at once.
>
> BTW I've always liked the way Solaris does this in that you can have
> many "zones" each with their own IP address and file system but there
> is only one instance of the operating system running on the hardware.
>  I always thought it a waste to have multiple copies of the same
> software in RAM, Sun solved that problem well.

I agree with your sentiment of not running untested configurations. The 
deployment/environment setup should also be automated but with manual 
oversight. That usually ensures all the steps to setup the environment are 
followed but any issues can be handled at the time and not found out the next 
morning. I guess it depends on how much business value the website brings 
whether this is worth it :)

The ip address change might be atomic but this only works if there is no state 
stored in the webserver/appserver. Any stateful sessions will be lost. Still, 
for single physical server sites it's a nice approach. If there is more than 
one physical machine involved then switching the loadbalancer policy would do 
the same trick. This then relies on having enough spare server capacity to 
support the two environments running at the same time though this could be 
mitigated by doing the switchover at a quiet time. Sometimes it just isn't 
possible to do an atomic switchover. For example, if a backend service also 
needs to be updated or a database schema needs changed.

-- 

__
Sword Ciboodle is the trading name of ciboodle Limited (a company 
registered in Scotland with registered number SC143434 and whose 
registered office is at India of Inchinnan, Renfrewshire, UK, 
PA4 9LH) which is part of the Sword Group of companies.

This email (and any attachments) is intended for the named
recipient(s) and is private and confidential. If it is not for you, 
please inform us and then delete it. If you are not the intended 
recipient(s), the use, disclosure, copying or distribution of any 
information contained within this email is prohibited. Messages to 
and from us may be monitored. If the content is not about the 
business of the Sword Group then the message is neither from nor 
sanctioned by us.

Internet communications are not secure. You should scan this
message and any attachments for viruses. Under no circumstances
do we accept liability for any loss or damage which may result from
your receipt of this email or any attachment.
__



svn 1.7 slow with many dirs

2011-02-27 Thread Gunnar Dalsnes

Hi,

My WC have 1881dirs and 12693 files, and I am experiencing extreme 
slowness in some situations:
'svn propget svn:dummyprop -R' in WC root take 70seconds! In svn 1.6 it 
take 2 seconds.

In WC's with around 200dirs, it's only take a few seconds in svn 1.7 too.

Discovered the problem while testing TortoiseSVN, where 
svn_wc_revision_status2 took 70seconds on WC root.


Seems svn_wc__node_walk_children/walker_helper is slow. Does not seem to 
scale linear.


Strangely, 'svn stat -v > nul' in WC root only take 2 seconds, and it is 
also recursive and traverse all nodes in WC, so there seem to be several 
implementations of walking nodes in wc.db, where one is fast.


Gunnar Dalsnes


Re: R: troubles running on Win 7 x64

2011-02-27 Thread Branko Čibej
On 26.02.2011 20:42, Paolo Di Pietro wrote:
> Sorry for having posted the wrong mailing list.
>
> By the way, I tried both http:// and https:// with the same result.
>
> With svn:// the error is slightly different:  it says 'can't connect to host'
>
> Any help?
>
> Paolo
>
>
> -Messaggio originale-
> Da: Branko Čibej [mailto:br...@xbc.nu] Per conto di Branko Cibej
> Inviato: sabato 26 febbraio 2011 20:29
> A: d...@subversion.apache.org
> Oggetto: Re: troubles running on Win 7 x64
>
> On 26.02.2011 12:36, Paolo Di Pietro wrote:
>> Hi all,
>>
>> I just downloaded latest x64 version and try to installi it  on my win 7 x64 
>> running on a wmvare workstation.
>>
>> TortoiseSVN 1.6.12, Build 20536 - 64 Bit , 2010/11/24 20:59:01 
>> Subversion 1.6.15, apr 1.3.8 apr-utils 1.3.9 neon 0.29.5 OpenSSL 
>> 0.9.8p 16 Nov 2010 zlib 1.2.3
>>
>> No problem with the installation, but after restarting it is not able to 
>> connect to the server.
>> The server is sunning on another machine on the network, and I can connect 
>> with my other installations running on windows 7 x32 running on the same 
>> vmware. 
>>
>> There is no apparent error, but the repo browser option have been there, 
>> with no answer, all over the night. 
>> On the same time, I saw a lot of traffic from my NAS, traffic going back to 
>> normal usage after I killed the repo browser process.
>>
>> I also installed the same x64 version on the host machine, a quadcore x64 
>> workstation running Win/ ultimate.
>> In this case I cannot connect to the server, but the response was different, 
>> giving the following message.
>>
>> Command: Checkout from 
>> http://silv.eidos.local/svn/arianna/arianna-2011/trunk, revision HEAD, Fully 
>> recursive, Externals included  
>> Error: Server sent unexpected return value (501 Not Implemented) in response 
>> to   
>> Error: OPTIONS request for 
>> 'http://silv.eidos.local/svn/arianna/arianna-2011/trunk'  
>> Finished!
>>
>> Anyone can help or have any suggestion?
> Yes, ask on the users@subversion.apache.org mailing list, which is the right 
> one to answer support questions on.
>
> But before you do that, try replacing that http:// with svn://.

You're either not running the Subversion server, or the firewall on your
server is blocking connections.

-- Brane



Re: Subversion 1.6.15, swig 1.3.36, python 2.6.6 - make check-swig-py fails

2011-02-27 Thread Peter Pommelich
Hi,

sorry for that late reply, but I was kind of busy the last days.

Finally with your help I was able to get the solution which indeed had 
something to do with shared/no shared libraries thing.

So, thanks again!

Kind regards,
Pete
-Ursprüngliche Nachricht-
Von: "Peter Pommelich" 
Gesendet: 16-Feb-2011 17:59:42
An: "Stefan Sperling" 
Betreff: Re: Subversion 1.6.15, swig 1.3.36, python 2.6.6 - make check-swig-py 
fails

>Hi,
>
>sorry, I did not read this email before I sent my own reply.
>
>Thanks for that, I'll give it a try asap.
>
>Kind regards,
>Pete
>
>-Ursprüngliche Nachricht-
>Von: "Stefan Sperling" 
>Gesendet: 16.02.2011 15:44:59
>An: "Peter Pommelich" 
>Betreff: Re: Subversion 1.6.15, swig 1.3.36, python 2.6.6 - make check-swig-py 
>fails
>
>>On Wed, Feb 16, 2011 at 02:43:19PM +0100, Peter Pommelich wrote:
>>> Hi everybody,
>>> 
>>> I need a subversion installation with swig and python bindings. I tried for 
>>> two day now to get this up. But I get ever time the same error message (see 
>>> bottom of this email).
>>> 
>>> But first some environment information. All sources have to be build and 
>>> installed in user's directory.
>>> 
>>> uname -a
>>> >>SunOS 5.10 Generic_144488-01 sun4v sparc SUNW,T5240
>>> subversion: 1.6.15
>>> swig: 1.3.36
>>> python: 2.6.6
>>> openssl-0.9.8q
>>> 
>>> python, openssl and swig compiled with gcc-4.4.0
>>> 
>>> ~/opt/swig-1.3.36/bin/swig -version: 
>>> >> SWIG Version 1.3.36
>>> >>
>>> >> Compiled with g++ [sparc-sun-solaris2.10]
>>> 
>>> ~/opt/python-2.6.6/bin/python -V
>>> >> Python 2.6.6
>>>  
>>> ~/opt/openssl-0.9.8q/bin/openssl version
>>> >> OpenSSL 0.9.8q 2 Dec 2010
>>> - 
>>> Now to the point. Every command is executed from within subversion's source 
>>> root directory (in this case '~/building/buildSVN/subversion-1.6.15'). 
>>> Please note that I replaced the user's home dir by '' because 
>>> it's quite a long path.
>>> 
>>> Subversion is configured with:
>>> ./configure PYTHON=/opt/python-2.6.6/bin/python 
>>> --with-swig=/opt/swig-1.3.36/bin/swig 
>>> --prefix=/opt/svn-1.6.15 --with-ssl 
>>> --with-openssl=/opt/openssl-0.9.8q 
>>> --with-libs=/opt/openssl-0.9.8q 
>>> -> No error
>>> 
>>> ~/opt/make-3.81/bin/make -j7 local-all
>>> -> No error
>>> 
>>> ~/opt/make-3.81/bin/make install
>>> -> No error
>>> 
>>> make swig-py
>>> -> no error
>>> 
>>> make check-swig-py
>>> ->cd 
>>> /building/buildSVN/subversion-1.6.15/subversion/bindings/swig/python;
>>>  \
>>>   /opt/python-2.6.6/bin/python 
>>> /building/buildSVN/subversion-1.6.15/subversion/bindings/swig/python/tests/run_all.py
>>> Traceback (most recent call last):
>>>   File 
>>> "/building/buildSVN/subversion-1.6.15/subversion/bindings/swig/python/tests/run_all.py",
>>>  line 2, in 
>>> import mergeinfo, core, client, delta, pool, ra, wc, repository, auth, \
>>>   File 
>>> "/building/buildSVN/subversion-1.6.15/subversion/bindings/swig/python/tests/mergeinfo.py",
>>>  line 14, in 
>>> from svn import core, repos, fs
>>>   File 
>>> "/building/buildSVN/subversion-1.6.15/subversion/bindings/swig/python/svn/core.py",
>>>  line 19, in 
>>> from libsvn.core import *
>>>   File 
>>> "/building/buildSVN/subversion-1.6.15/subversion/bindings/swig/python/libsvn/core.py",
>>>  line 7, in 
>>> import _core
>>> ImportError: No module named _core
>>> *** Error code 1
>>> make: Fatal error: Command failed for target `check-swig-py'
>>
>>This usually happens because python cannot dlopen() the shared libraries
>>needed by the SVN bindings. You are seeing this because you've installed
>>the svn libs into a non-standard search path (e.g. if you had used
>>--prefix=/usr/local it would likely just work because the libs would
>>be found in /usr/local/lib).
>>
>>Just like you need to add ~/opt/*/bin directories to your PATH to run
>>the executables you've installed, you need to add all directories
>>containing libraries that will be dynamically loaded at runtime
>>to LD_LIBRARY_PATH.
>>
>>Something like this:
>> export LD_LIBRARY_PATH=/opt/svn-1.6.15/lib
>>
>>You may need even more entries in this list if those libs depend
>>on other libraries that aren't in the standard search path either.
>___
>Schon gehört? WEB.DE hat einen genialen Phishing-Filter in die
>Toolbar eingebaut! http://produkte.web.de/go/toolbar
___
WEB.DE DSL Doppel-Flat ab 19,99 €/mtl.! Jetzt mit 
gratis Handy-Flat! http://produkte.web.de/go/DSL_Doppel_Flatrate/2


Modification Required in " pre-revprop-change.bat "

2011-02-27 Thread Waseem Bokhari
Hi Guys!
This script only allow Authors to edit their comments in SVN. I would like
to edit this in such a way that ONLY specific email group or users can edit
comments. >  NOT ALL 

Please help me in this regard.

+
@ECHO OFF
:: Set all parameters. Even though most are not used, in case you want to
add
:: changes that allow, for example, editing of the author or addition of log
messages.
set repository=%1
set revision=%2
set userName=%3
set propertyName=%4
set action=%5

:: Only allow the log message to be changed, but not author, etc.
if /I not "%propertyName%" == "svn:log" goto ERROR_PROPNAME

:: Only allow modification of a log message, not addition or deletion.
if /I not "%action%" == "M" goto ERROR_ACTION

:: Make sure that the new svn:log message is not empty.
set bIsEmpty=true
for /f "tokens=*" %%g in ('find /V ""') do (
set bIsEmpty=false
)
if "%bIsEmpty%" == "true" goto ERROR_EMPTY

goto :eof

:ERROR_EMPTY
echo Empty svn:log messages are not allowed. >&2
goto ERROR_EXIT

:ERROR_PROPNAME
echo Only changes to svn:log messages are allowed. >&2
goto ERROR_EXIT

:ERROR_ACTION
echo Only modifications to svn:log revision properties are allowed. >&2
goto ERROR_EXIT

:ERROR_EXIT
exit /b 1



Gracias
 


DISCLAIMER:  This e-mail and any file transmitted with it are confidential and 
intended solely 
for the use of the addressee.  If you are not the intended recipient, you are 
hereby advised that
any dissemination, distribution or copy of this email or its attachments is 
strictly prohibited.  If you
have received this email in error, please immediately notify us by return email 
and destroy this email 
message and its attachments.  This communication may contain forward-looking 
statements
relating to the development of NetSol Technologies' products and services and 
future operations.
The words "believe," "expect," "anticipate," "intend," variations of such 
words, and similar 
expressions, identify forward looking statements, but their absence does not 
mean that the 
statement is not forward-looking.  Views and opinions contained herein are 
those of the author of 
this email and do not necessarily represent those of NetSol Technologies.  
Statements contained 
herein are not guarantees of future performance and are subject to certain 
risks, uncertainties and 
assumptions that are difficult to predict. The company will not undertake to 
update any statements 
contained herein.

WARNING: The recipient should check this email and any attachment for the 
presence of viruses. 
Although the company has taken reasonable precautions to ensure no viruses are 
present in this 
email, the company does not accept responsibility for any loss or damage 
arising from the use of 
this email or attachment. Note: Please consider the environment before printing 
this e-mail.