SVN 1.4.6 support exit codes

2010-03-17 Thread Charan
Hi,

does SVN support exit codes. Suppose if I use "svn merge" in my shell
script, will svn be able to return exit code "0" if the merge is successful.


Thanks,
Charan


Re: Documentation of historical URI feature

2010-03-17 Thread Tyler Roscoe
On Thu, Mar 18, 2010 at 11:50:23AM +0900, Craig McQueen wrote:
> Comparing:
> http://subversion.apache.org/docs/release-notes/1.6.html#historical-uris
> http://svnbook.red-bean.com/nightly/en/svn.serverconfig.httpd.html#svn.serverconfig.httpd.extra.browsing
>  
> (namely the box "Can I View Older Revisions?")
> 
> It seems the latter is out-of-date. Should I submit an issue at:
> http://subversion.apache.org/issue-tracker.html

The svnbook folks have a separate issue tracker:

http://code.google.com/p/svnbook/issues/list

tyler


Documentation of historical URI feature

2010-03-17 Thread Craig McQueen

Hello,

Comparing:
http://subversion.apache.org/docs/release-notes/1.6.html#historical-uris
http://svnbook.red-bean.com/nightly/en/svn.serverconfig.httpd.html#svn.serverconfig.httpd.extra.browsing 
(namely the box "Can I View Older Revisions?")


It seems the latter is out-of-date. Should I submit an issue at:
http://subversion.apache.org/issue-tracker.html

Regards,
Craig McQueen



Re: file:/// protocol based svn repository questions

2010-03-17 Thread David Weintraub
You should NEVER use the file:// protocol unless you are the only
person using the repository, and the repository is only accessible by
you.

The file:// protocol requires read and write permissions on all files
in the repository for the user who is doing the committing. This means
that instead of using Subversion commands, the user can munge the
repository directly. For example, the user could copy the repository,
manipulate the items in it, and then replace it with the munged copy.

Even worse, if user "bob" does a commit, the version file is now owned
by "bob", and if the rights aren't setup correctly, only "bob" might
be able to read and write that version.

I don't know if there are concurrency issues, but I don't even use
file:// when I am creating my own temporary repositories.

I understand why you may not want to use Apache's http as your server.
That can be a bit of a bear to setup. However, the svnserve server is
quick and simple to setup. It is definitely easier to use than shared
Windows directories and affords you full client/server protection.

You should seriously consider not using the file:// protocol.

On Wed, Mar 17, 2010 at 11:30 AM, Jeff Marver  wrote:
> Hi all,
>
>
>
> We're using SharpSVN.SvnRepositoryClient.CreateRepository to create file:///
> protocol based svn repositories on shared Windows network drives. Can anyone
> tell me the exact permissions a Windows user will need to fully interact
> with the repository? We're recently run into a user that was able to lock a
> file but couldn't do a commit, the error indicated that the commit failed
> and a .tmp file couldn't be moved since it already existed in txn-current?
> The customer indicated that they had read and write access??
>
>
>
> Also, I've seen quite a few posts on the Internet suggesting that sharing a
> file:/// protocol based svn repository is not recommended for multiple users
> and even discouraged. Can anyone confirm or refute this information?
>
>
>
> Thanks!
>
>
>
> Jeff



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


unsubscribe t...@specialistdevelopment.com

2010-03-17 Thread Anthony Davis
unsubscribe t...@specialistdevelopment.com


Re: Change email address.

2010-03-17 Thread Anthony Davis
Thankyou :)

Tony


On 17 Mar 2010, at 21:05, Tyler Roscoe wrote:

> On Wed, Mar 17, 2010 at 08:41:04PM +, Anthony Davis wrote:
>> Sorry to ask this to the list, but i cant find any documents about it,
>> I need to change my svn mailing list address, how can I do this
>> please?
> 
> unsubscribe old address.
> subscribe new address.
> 
> pretty sure that's the easiest/best/only way.
> 
> tyler



Re: Change email address.

2010-03-17 Thread Tyler Roscoe
On Wed, Mar 17, 2010 at 08:41:04PM +, Anthony Davis wrote:
> Sorry to ask this to the list, but i cant find any documents about it,
> I need to change my svn mailing list address, how can I do this
> please?

unsubscribe old address.
subscribe new address.

pretty sure that's the easiest/best/only way.

tyler


Change email address.

2010-03-17 Thread Anthony Davis
Hi,

Sorry to ask this to the list, but i cant find any documents about it, I need 
to change my svn mailing list address, how can I do this please?

Kind Regards

Tony

Re: NTLM proxy authentication credentials

2010-03-17 Thread Carsten Fuchs

On 17.03.2010 20:31, Carsten Fuchs wrote:

using svn-1.6.6 on Windows Server 2003, I experience the same problem as
described by Yann Eads at

http://svn.haxx.se/dev/archive-2008-02/0693.shtml


Btw, the original thread at the TSVN mailing list is at
http://svn.haxx.se/tsvnusers/archive-2008-02/index.shtml#259

Best regards,
Carsten



--
   Cafu - the open-source Game and Graphics Engine
for multiplayer, cross-platform, real-time 3D Action
  Learn more at www.cafu.de



smime.p7s
Description: S/MIME Cryptographic Signature


NTLM proxy authentication credentials

2010-03-17 Thread Carsten Fuchs

Hi all,

using svn-1.6.6 on Windows Server 2003, I experience the same problem as 
described by Yann Eads at

http://svn.haxx.se/dev/archive-2008-02/0693.shtml

In summary, proxy authentication via NTLM fails, because even though the proxy credentials are 
properly specified in the "server" config file, i.e. like



[global]

http-proxy-host = ...
http-proxy-port = ...
http-proxy-username = ...
http-proxy-password = ...


these credential are not used in the NTLM replies (but instead those of the 
Windows user login).

Anything that can be done about it?
I'd be very grateful for any help.

Best regards,
Carsten

PS: I was able to come up with a work-around, using 
http://cntlm.sourceforge.net/ ...




--
   Cafu - the open-source Game and Graphics Engine
for multiplayer, cross-platform, real-time 3D Action
   Learn more at http://www.cafu.de



smime.p7s
Description: S/MIME Cryptographic Signature


RE: 403 Forbidden in response to COPY request

2010-03-17 Thread Jon Foster
Hi,

Anton Prowse wrote:
[...]
> [/trunk/specialfile]
> user2 =
[...]
> when I authenticate as user2 I receive the following error
> when trying to create a branch from the trunk of "repos1":
> Server sent unexpected return value (403 Forbidden) in
> response to COPY request for '/repos/repos1/!svn/bc/999/trunk'

user2 is trying to copy /trunk/specialfile to somewhere where he'd
be able to read it.  So Subversion blocks it.  In order to create
a branch from trunk, you need read access to trunk and every file
inside it.

Perhaps /trunk/specialfile can be moved somewhere else, so you can
remove this restrictive permission?  (This may require you to dump
the repository and use "svndumpfilter" to get rid of the historical
revisions of /trunk/specialfile).

Kind regards,
 
Jon

--
(Please direct all replies to the mailing list)


**
This email and its attachments may be confidential and are intended solely for 
the use of the individual to whom it is addressed. Any views or opinions 
expressed are solely those of the author and do not necessarily represent those 
of Cabot Communications Ltd.

If you are not the intended recipient of this email and its attachments, you 
must take no action based upon them, nor must you copy or show them to anyone.

Cabot Communications Limited
Verona House, Filwood Road, Bristol BS16 3RY, UK
+44 (0) 1179584232

Co. Registered in England number 02817269

Please contact the sender if you believe you have received this email in error.

**


__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
__


RE: SVN and Windows/Linux permissions

2010-03-17 Thread Jeff.Drake
Good eye, it is Microsoft SFU. If SVN won't track how I think the devs have 
asked for it, we'll have to wait until their code is re-factored to obviate the 
whole problem.  
Thanks much.  

-JDrake


-Original Message-
From: Tyler Roscoe [mailto:ty...@cryptio.net] 
Sent: Wednesday, March 17, 2010 1:24 PM
To: Andy Levy
Cc: Drake, Jeff (CCI-Atlanta); users@subversion.apache.org
Subject: Re: SVN and Windows/Linux permissions

On Wed, Mar 17, 2010 at 01:02:10PM -0400, Andy Levy wrote:
> On Wed, Mar 17, 2010 at 12:40,   wrote:
> > This might not really be a SVN question, but somebody may have encountered
> > it. I need to be able to export code from windows hosted SVN (Apache/2.0.58
> > (Win32) DAV/2 SVN/1.3.1) and maintain linux permissions set by linux clients
> > at commit time.   I typically get permissions that omit the group and other
> > permissions, like so:
> >
> > Y:\ls -altr

How are you running ls on a Windows box? If this is Cygwin, that's
another variable which might alter the permissions on checked-out files.

> > Do I *have* to dl to a linux partition, will windows always strip some unix
> > permissions?
> 
> Subversion doesn't track/manage permissions beyond +x (executable).
> 
> If you're connecting to a SAMBA share from Windows and doing an export
> there, it's down to your SAMBA configuration.

Also, check your umask settings.

tyler


Re: SVN and Windows/Linux permissions

2010-03-17 Thread Andy Levy
On Wed, Mar 17, 2010 at 13:28,   wrote:
> The svn:executable property is maintained, the devs need some more 
> granularity unfortunately. We aren't connecting over samba, our export is to 
> local disk.

Subversion doesn't track permissions like you're wanting.

Maybe have your build/export script set the permissions as part of your process?

> -Original Message-
> From: Andy Levy [mailto:andy.l...@gmail.com]
> Sent: Wednesday, March 17, 2010 1:02 PM
> To: Drake, Jeff (CCI-Atlanta)
> Cc: users@subversion.apache.org
> Subject: Re: SVN and Windows/Linux permissions
>
> On Wed, Mar 17, 2010 at 12:40,   wrote:
>> This might not really be a SVN question, but somebody may have encountered
>> it. I need to be able to export code from windows hosted SVN (Apache/2.0.58
>> (Win32) DAV/2 SVN/1.3.1) and maintain linux permissions set by linux clients
>> at commit time.   I typically get permissions that omit the group and other
>> permissions, like so:
>>
>>
>>
>> Y:\ls -altr
>>
>> total 77
>>
>> -rwx--+ 1 +Administrators  Domain Users    686 Mar 17 12:25 run.sh
>>
>>
>>
>> Do I *have* to dl to a linux partition, will windows always strip some unix
>> permissions?
>
> Subversion doesn't track/manage permissions beyond +x (executable).
>
> If you're connecting to a SAMBA share from Windows and doing an export
> there, it's down to your SAMBA configuration.
>


RE: SVN and Windows/Linux permissions

2010-03-17 Thread Jeff.Drake
The svn:executable property is maintained, the devs need some more granularity 
unfortunately. We aren't connecting over samba, our export is to local disk.  

-JDrake


-Original Message-
From: Andy Levy [mailto:andy.l...@gmail.com] 
Sent: Wednesday, March 17, 2010 1:02 PM
To: Drake, Jeff (CCI-Atlanta)
Cc: users@subversion.apache.org
Subject: Re: SVN and Windows/Linux permissions

On Wed, Mar 17, 2010 at 12:40,   wrote:
> This might not really be a SVN question, but somebody may have encountered
> it. I need to be able to export code from windows hosted SVN (Apache/2.0.58
> (Win32) DAV/2 SVN/1.3.1) and maintain linux permissions set by linux clients
> at commit time.   I typically get permissions that omit the group and other
> permissions, like so:
>
>
>
> Y:\ls -altr
>
> total 77
>
> -rwx--+ 1 +Administrators  Domain Users    686 Mar 17 12:25 run.sh
>
>
>
> Do I *have* to dl to a linux partition, will windows always strip some unix
> permissions?

Subversion doesn't track/manage permissions beyond +x (executable).

If you're connecting to a SAMBA share from Windows and doing an export
there, it's down to your SAMBA configuration.


Re: SVN and Windows/Linux permissions

2010-03-17 Thread Tyler Roscoe
On Wed, Mar 17, 2010 at 01:02:10PM -0400, Andy Levy wrote:
> On Wed, Mar 17, 2010 at 12:40,   wrote:
> > This might not really be a SVN question, but somebody may have encountered
> > it. I need to be able to export code from windows hosted SVN (Apache/2.0.58
> > (Win32) DAV/2 SVN/1.3.1) and maintain linux permissions set by linux clients
> > at commit time.   I typically get permissions that omit the group and other
> > permissions, like so:
> >
> > Y:\ls -altr

How are you running ls on a Windows box? If this is Cygwin, that's
another variable which might alter the permissions on checked-out files.

> > Do I *have* to dl to a linux partition, will windows always strip some unix
> > permissions?
> 
> Subversion doesn't track/manage permissions beyond +x (executable).
> 
> If you're connecting to a SAMBA share from Windows and doing an export
> there, it's down to your SAMBA configuration.

Also, check your umask settings.

tyler


Re: SVN and Windows/Linux permissions

2010-03-17 Thread Andy Levy
On Wed, Mar 17, 2010 at 12:40,   wrote:
> This might not really be a SVN question, but somebody may have encountered
> it. I need to be able to export code from windows hosted SVN (Apache/2.0.58
> (Win32) DAV/2 SVN/1.3.1) and maintain linux permissions set by linux clients
> at commit time.   I typically get permissions that omit the group and other
> permissions, like so:
>
>
>
> Y:\ls -altr
>
> total 77
>
> -rwx--+ 1 +Administrators  Domain Users    686 Mar 17 12:25 run.sh
>
>
>
> Do I *have* to dl to a linux partition, will windows always strip some unix
> permissions?

Subversion doesn't track/manage permissions beyond +x (executable).

If you're connecting to a SAMBA share from Windows and doing an export
there, it's down to your SAMBA configuration.


SVN and Windows/Linux permissions

2010-03-17 Thread Jeff.Drake
This might not really be a SVN question, but somebody may have encountered it. 
I need to be able to export code from windows hosted SVN (Apache/2.0.58 (Win32) 
DAV/2 SVN/1.3.1) and maintain linux permissions set by linux clients at commit 
time.   I typically get permissions that omit the group and other permissions, 
like so:

Y:\ls -altr
total 77
-rwx--+ 1 +Administrators  Domain Users686 Mar 17 12:25 run.sh

Do I *have* to dl to a linux partition, will windows always strip some unix 
permissions?



Re: Log excluding svn:mergeinfo changes

2010-03-17 Thread Stefan Sperling
On Wed, Mar 17, 2010 at 10:54:29AM -0500, Thomas S. Trias wrote:
> I will gladly lend time and energy as available; I envision even
> more affected commands, such as info and ls for their last committed
> revision calculation.

Great, that's very much appreciated!

If you haven't done so, you might want to peek into the community
guide for pointers about starting to contribute:
http://subversion.apache.org/docs/community-guide/

If you have questions, just ask! If you have patches, please send them. 
Even if you don't feel confident about your patches at first, showing
them to developers and digesting feedback will help you become confident
about them quickly.

Thanks,
Stefan


Re: Log excluding svn:mergeinfo changes

2010-03-17 Thread Thomas S. Trias
I will gladly lend time and energy as available; I envision even more 
affected commands, such as info and ls for their last committed revision 
calculation.


Thanks,

Thomas S. Trias
Senior Developer
Artizan Internet Services
http://www.artizan.com/



 Original Message  
Subject: Re: Log excluding svn:mergeinfo changes
From: Stefan Sperling 
To: eg 
Cc: "Thomas S. Trias" , users@subversion.apache.org
Date: 3/17/2010 5:05 AM

On Tue, Mar 16, 2010 at 05:26:47PM -0700, eg wrote:
  

On 3/15/2010 9:12 AM, Stefan Sperling wrote:



There is an experimental branch which is aimed at implementing
what you need:
http://svn.apache.org/repos/asf/subversion/branches/ignore-mergeinfo/BRANCH-README

I don't know what the status of this branch is, though.
It looks like work on it has been suspended, possibly because
Hyrum (who started this branch) is uber-busy with the ongoing
working copy implementation re-write and other duties.

  

I wonder if that might be a good candidate for a Google summer of
code project?



Yes! Thanks for pointing that out. (I am looking for gsoc project
ideas but couldn't see the forrest for the trees with this one...)


  




Re: file:/// protocol based svn repository questions

2010-03-17 Thread Andy Levy
On Wed, Mar 17, 2010 at 11:30, Jeff Marver  wrote:
> Hi all,
>
>
>
> We're using SharpSVN.SvnRepositoryClient.CreateRepository to create file:///
> protocol based svn repositories on shared Windows network drives. Can anyone
> tell me the exact permissions a Windows user will need to fully interact
> with the repository? We're recently run into a user that was able to lock a
> file but couldn't do a commit, the error indicated that the commit failed
> and a .tmp file couldn't be moved since it already existed in txn-current?
> The customer indicated that they had read and write access??

Full control.

>
> Also, I've seen quite a few posts on the Internet suggesting that sharing a
> file:/// protocol based svn repository is not recommended for multiple users
> and even discouraged. Can anyone confirm or refute this information?

Very bad idea. When you do this, anyone can corrupt or even delete the
whole repository with one errant keystroke. And you have no path-based
authorization. If someone uses a newer client with the repository,
older ones may not be able to read it. There /may/ be concurrency
concerns as well, but I'm not 100% sure on that.

Have a look at the final bullet point on
http://svnbook.red-bean.com/en/1.5/svn.serverconfig.choosing.html

Set up a proper SVN server, you'll be much better off.


file:/// protocol based svn repository questions

2010-03-17 Thread Jeff Marver
Hi all,

 

We're using SharpSVN.SvnReposito​ryClient.CreateRepos​itory to create file:/// 
protocol based svn repositories on shared Windows network drives. Can anyone 
tell me the exact permissions a Windows user will need to fully interact with 
the repository? We're recently run into a user that was able to lock a file but 
couldn't do a commit, the error indicated that the commit failed and a .tmp 
file couldn't be moved since it already existed in txn-current? The customer 
indicated that they had read and write access??

 

Also, I've seen quite a few posts on the Internet suggesting that sharing a 
file:/// protocol based svn repository is not recommended for multiple users 
and even discouraged. Can anyone confirm or refute this information? 

 

Thanks!

 

Jeff



Re: 403 Forbidden in response to COPY request

2010-03-17 Thread Anton Prowse
From: Bob Archer 
Date: 17/03/2010 15:32

>> Several users are configured to use our Subversion system via HTTPS and
>> Basic authentication.
>>
>> Repos URL:
>> https://www.example.com/repos/repos1/trunk
>>
>>
>> Apache config "vhost_ssl.conf":
>>
>> 
>> DAV svn
>> SVNParentPath /var/www/svn
>>
>> AuthzSVNAccessFile /var/www/vhosts/example.com/conf/reposAccessFile
>>
>> AuthType Basic
>> AuthName "Traffic Subversion Repository"
>> AuthUserFile /var/www/vhosts/example.com/conf/svnuserpw
>> require valid-user
>> 
>>
>>
>> reposAccessFile:
>>
>> [specialrepos:/]
>> * = rw
>>
>> [specialrepos:/trunk]
>> user2 =
>>
>> [specialrepos:/branches]
>> user2 =
>>
>> [specialrepos:/tags]
>> user2 =
>>
>> [/trunk/specialfile]
>> user2 =
>>
>> [/]
>> * = rw
>>
>>
>> svnuserpw file:
>> user1:
>> user2:
>>
>>
>> When I authenticate as user1 I can execute all commands without problem.
>> However, when I authenticate as user2 I receive the following error when
>> trying to create a branch from the trunk of "repos1":
>>
>>> svn: COPY of branches/test: 403 Forbidden (https://www.example.com)

> I think this is a known issue. You have to give user2 read access to the root 
> path in order for him to be able to create branches. that is the difference 
> between user1 and user2. User1 has rw access to /.

Sorry, I don't follow you; doesn't everyone have access to / due to the 
following lines?

[/]
* = rw

Cheers,
Anton Prowse

TRAVELCLICK Privacy Policy

This email message and any accompanying attachments may contain confidential 
information. If you are not the intended recipient, do not read, use, 
disseminate, distribute or copy this message or attachments. If you have 
received this message in error, please notify the sender immediately and delete 
this message. Any views expressed in this message are those of the individual 
sender, except where the sender expressly, and with authority, states them to 
be the views of TravelCLICK.  Before opening any attachments, please check them 
for viruses and defects.



Re: Installing two subversion release on the same machine

2010-03-17 Thread Stefan Sperling
On Wed, Mar 17, 2010 at 02:46:47PM +0100, emiliano.mon...@eu.steria.be wrote:
> Hallo,
> 
> I'm new comer in Subversion users mailing list and I want post my first 
> question:
> I have Subversion 1.4.5 release up and running over a Linux CentOS 
> machine. Due to I would like to upgrade Subversion to 1.6.9 release, I 
> would like to know if it is possible to install two Subversion release on 
> the same machine without performing upgrade of the old one.

It's possible. Just make sure to install both into a different prefix.
E.g. if you build from source, install both into separate prefixes:
For 1.4.5:
  ./configure --prefix=/usr/local/svn-1.4.5
For 1.6.9:
  ./configure --prefix=/usr/local/svn-1.6.9

E.g. on my system I currently have two svn trunk builds, and one 1.5.x
build (the branch from which the next 1.5 release will be made, if ever)
and one svn-1.6.x build (the branch from which the next 1.6 release will
be made) installed in my home directory:

$ ls ~/svn/prefix
apr/ httpd/   serf/svn-1.5.x/   svn-trunk/
bdb/ neon/sqlite/  svn-1.6.x/   svn-trunk2/
$ which svn
/home/stsp/svn/prefix/svn-trunk/bin/svn

If you use binary packages, the content of binary packages will probably
overlap, e.g. both trying to install /usr/bin/svn. In this case you cannot
install both at the same time (unless there is a way to install an RPM into
a different directory than the root directory '/' --  I don't know if
that's possible).

Stefan


RE: 403 Forbidden in response to COPY request

2010-03-17 Thread Bob Archer
> Several users are configured to use our Subversion system via HTTPS and
> Basic authentication.
> 
> Repos URL:
> https://www.example.com/repos/repos1/trunk
> 
> 
> Apache config "vhost_ssl.conf":
> 
> 
>     DAV svn
>     SVNParentPath /var/www/svn
> 
>     AuthzSVNAccessFile /var/www/vhosts/example.com/conf/reposAccessFile
> 
>     AuthType Basic
>     AuthName "Traffic Subversion Repository"
>     AuthUserFile /var/www/vhosts/example.com/conf/svnuserpw
>     require valid-user
> 
> 
> 
> reposAccessFile:
> 
> [specialrepos:/]
> * = rw
> 
> [specialrepos:/trunk]
> user2 =
> 
> [specialrepos:/branches]
> user2 =
> 
> [specialrepos:/tags]
> user2 =
> 
> [/trunk/specialfile]
> user2 =
> 
> [/]
> * = rw
> 
> 
> svnuserpw file:
> user1:
> user2:
> 
> 
> When I authenticate as user1 I can execute all commands without problem.
> However, when I authenticate as user2 I receive the following error when
> trying to create a branch from the trunk of "repos1":
> 
> Using TortoiseSVN from my local machine:
> > Copy C:\www\repos1 to
> https://www.example.com/repos/repos1/branches/test, Revision 999
> Server sent unexpected return value (403 Forbidden) in response to COPY
> request
> for '/repos/repos1/!svn/bc/999/trunk'
> 
> Using the command line from my local machine:
> > svn copy --username user2 https://www.example.com/repos/repos1/trunk
> https://www.example.com/repos/repos1/branches/test -r 999 -m ""
> > svn: COPY of branches/test4: 403 Forbidden (https://www.online-
> toolbox.com)
> 
> It works if I do it on the command line of the same server where the repos
> is actually stored, and I'm logged in as root:
> > svn copy --username user2 file:///var/www/svn/repos1/trunk
> file:///var/www/svn/repos1/branches/test -r 999 -m "" --no-auth-cache
> > Committed revision 2000.
> 
> but fails if I'm logged in on that same server as another user:
> > svn copy --username user2 file:///var/www/svn/repos1/trunk
> file:///var/www/svn/repos1/branches/test -r 999 -m "" --no-auth-cache
> > svn: Can't create directory '/var/www/svn/repos1/db/transactions/1999-
> 1.txn': Permission denied
> but this is presumably because only the "apache" operating system user has
> write access to the /var/www/svn folder:
> 
> drwxr-xr-x  123 apache apache    4096 Jan 1 2010 .
> drwxr-xr-x  1 root   root  4096 Jan 1 2010 ..
> drwxr-xr-x  12 apache apache    4096 Jan 1 2010 repos1
> drwxr-xr-x  12 apache apache    4096 Jan 1 2010 specialrepos
> 
> 
> I can't see what makes user2 different from user1 other than the
> configuration in reposAccessFile which only concerns an unrelated
> repository ("specialrepos") and a single file which exists in all
> repositories ("/trunk/specialfile").

I think this is a known issue. You have to give user2 read access to the root 
path in order for him to be able to create branches. that is the difference 
between user1 and user2. User1 has rw access to /.

BOb



Re: Installing two subversion release on the same machine

2010-03-17 Thread Ulrich Eckhardt
On Wednesday 17 March 2010, emiliano.mon...@eu.steria.be wrote:
> I have Subversion 1.4.5 release up and running over a Linux CentOS
> machine. Due to I would like to upgrade Subversion to 1.6.9 release, I
> would like to know if it is possible to install two Subversion release on
> the same machine without performing upgrade of the old one.

Yes, first you compile the thing:

 ./configure --prefix /path/to/folder/for/svn-1.6.9
 make install

Then, you only need to adjust your PATH and LD_LIBRARY_PATH so that the other 
location is found. This is also useful if you don't want to (or can't) 
install it systemwide (yet). You can install it in your home directory and 
don't screw up your system in case of mistakes, you don't even need root 
privileges.

Uli

-- 
ML: http://subversion.tigris.org/mailing-list-guidelines.html
FAQ: http://subversion.tigris.org/faq.html
Docs: http://svnbook.red-bean.com/

Sator Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932

**
Sator Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
**
   Visit our website at 
**
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. Sator Laser GmbH ist für diese Folgen nicht 
verantwortlich.
**



Installing two subversion release on the same machine

2010-03-17 Thread Emiliano . MONACO
Hallo,

I'm new comer in Subversion users mailing list and I want post my first 
question:
I have Subversion 1.4.5 release up and running over a Linux CentOS 
machine. Due to I would like to upgrade Subversion to 1.6.9 release, I 
would like to know if it is possible to install two Subversion release on 
the same machine without performing upgrade of the old one.

Regards,
Emiliano.

403 Forbidden in response to COPY request

2010-03-17 Thread Anton Prowse
Several users are configured to use our Subversion system via HTTPS and Basic 
authentication.

Repos URL:
https://www.example.com/repos/repos1/trunk


Apache config "vhost_ssl.conf":


DAV svn
SVNParentPath /var/www/svn

AuthzSVNAccessFile /var/www/vhosts/example.com/conf/reposAccessFile

AuthType Basic
AuthName "Traffic Subversion Repository"
AuthUserFile /var/www/vhosts/example.com/conf/svnuserpw
require valid-user



reposAccessFile:

[specialrepos:/] 
* = rw

[specialrepos:/trunk]
user2 =

[specialrepos:/branches]
user2 =

[specialrepos:/tags]
user2 =

[/trunk/specialfile]
user2 =

[/]
* = rw 


svnuserpw file:
user1:
user2:


When I authenticate as user1 I can execute all commands without problem.  
However, when I authenticate as user2 I receive the following error when trying 
to create a branch from the trunk of "repos1":

Using TortoiseSVN from my local machine:
> Copy C:\www\repos1 to https://www.example.com/repos/repos1/branches/test, 
> Revision 999
Server sent unexpected return value (403 Forbidden) in response to COPY request 
for '/repos/repos1/!svn/bc/999/trunk'

Using the command line from my local machine:
> svn copy --username user2 https://www.example.com/repos/repos1/trunk 
> https://www.example.com/repos/repos1/branches/test -r 999 -m ""
> svn: COPY of branches/test4: 403 Forbidden (https://www.online-toolbox.com)

It works if I do it on the command line of the same server where the repos is 
actually stored, and I'm logged in as root:
> svn copy --username user2 file:///var/www/svn/repos1/trunk 
> file:///var/www/svn/repos1/branches/test -r 999 -m "" --no-auth-cache
> Committed revision 2000.

but fails if I'm logged in on that same server as another user:
> svn copy --username user2 file:///var/www/svn/repos1/trunk 
> file:///var/www/svn/repos1/branches/test -r 999 -m "" --no-auth-cache
> svn: Can't create directory '/var/www/svn/repos1/db/transactions/1999-1.txn': 
> Permission denied
but this is presumably because only the "apache" operating system user has 
write access to the /var/www/svn folder:

drwxr-xr-x  123 apache apache4096 Jan 1 2010 .
drwxr-xr-x  1 root   root  4096 Jan 1 2010 ..
drwxr-xr-x  12 apache apache4096 Jan 1 2010 repos1
drwxr-xr-x  12 apache apache4096 Jan 1 2010 specialrepos


I can't see what makes user2 different from user1 other than the configuration 
in reposAccessFile which only concerns an unrelated repository ("specialrepos") 
and a single file which exists in all repositories ("/trunk/specialfile").

I'm using:
TortoiseSVN 1.6.5, Build 16974 - 32 Bit , 2009/08/20 08:13:46
Subversion 1.6.5, 
apr 1.3.8
apr-utils 1.3.9
neon 0.28.6
OpenSSL 0.9.8k 25 Mar 2009
zlib 1.2.3

Any advice will be much appreciated!

Cheers,
Anton Prowse 

TRAVELCLICK Privacy Policy

This email message and any accompanying attachments may contain confidential 
information. If you are not the intended recipient, do not read, use, 
disseminate, distribute or copy this message or attachments. If you have 
received this message in error, please notify the sender immediately and delete 
this message. Any views expressed in this message are those of the individual 
sender, except where the sender expressly, and with authority, states them to 
be the views of TravelCLICK.  Before opening any attachments, please check them 
for viruses and defects.



Re: Error "An existing connection was forcibly closed by the remote host" with F5 content switch or working copy on shared drive

2010-03-17 Thread Les Mikesell
This sounds like the checkout is just slow in creating files, triggering server 
timeouts that are probably configurable.  When talking directly to the server, 
this should be controlled by the apache 'TimeOut' directive which defaults to 
300 seconds.  It is also possible for intermediate NAT or firewall devices to 
time apparently inactive connections out but normally they would have a much 
longer timeout for tcp connections.


 -Les


Bert Huijben wrote:

Hi,

 

Subversion uses the neon (or serf) library for connecting with webdav 
repositories. It doesn't change any of the tcp settings itself, nor does 
it handle the tcp connections. (Neither of those has specific MTU 
handling or anything like that as far as I can tell. They just use the 
self-tuning support implemented in the operating system)


 

For the server side everything is handled by the Apache httpd process 
and our mod_dav_svn just receives the pre-parsed requests; so no tcp 
handling there in the Subversion layer either.


 

So I don't think the Subversion project can really fix this for you (as 
part of Subversion). But you might find the developers of the other 
projects on our development list. (Neon, Serf, Neon and Apache Httpd 
have development lists themselves too)


 


Bert

 


*From:* Justin Johnson [mailto:jus...@honesthacker.com]
*Sent:* woensdag 17 maart 2010 12:47
*To:* users@subversion.apache.org
*Subject:* Re: Error "An existing connection was forcibly closed by the 
remote host" with F5 content switch or working copy on shared drive


 

On Fri, Mar 12, 2010 at 9:34 AM, Justin Johnson > wrote:


Hi,

I'm trying to understand why the following error occurs.

svn: REPORT request failed on '/svn/reponame/!svn/vcc/default'
svn: REPORT of '/svn/reponame/!svn/vcc/default': Could not read response 
body: An existing connection was forcibly closed by the remote host.   
(http://HOSTNAME )

command exit code: 1

I've seen this error in a couple of scenarios:
1) when performing a checkout on a Windows box with the working copy 
stored on a drive mapped to a NAS share
2) when performing a checkout on a Windows box and the server is an F5 
content switch that just redirects traffic to the Subversion server


The first scenario is of less concern to me, but I mention it anyway 
since I think it is the same problem.


For the second scenario, I worked with someone on our networking team to 
understand the problem.  What he discovered and how he "resolved" it 
with our F5 content switch can be found below.  The server is running 
Solaris 10, Subversion 1.6.6, Apache 2.2.11, and repositories are served 
via HTTP.  The client is running Windows XP SP3 and Subversion 1.6.7 
(error occurs with TortoiseSVN as well), but the error also occurs on 
Windows Server 2003.  I haven't tested any other Windows client OSes and 
haven't seen the error on UNIX, but suspect the underlying problem may 
exist there and the OS handles it more gracefully.  Here is the 
explanation by my networking contact.




The problem that is presenting is that the client's receive buffer is 
filling up and staying full for a long period of time.  When this 
occurs, he advertises a tcp window size of 0 in packets he sends to the 
destination F5.  This also happens when he goes directly against a 
server.  The server seems to tolerate it while the F5 does not. 

 

Last year,  I took traces of the traffic against the server by the 
client directly, and through the F5, and saw that the server was seeing 
different MTU and options from the F5.   I modified the standard TCP 
profile on the F5 to have it proxy the TCP options the client offered so 
the server would get them.  I also set it to proxy the MTU setting the 
client offered. This seemed to have fixed the problem at that time.  But 
your current testing failed. 

 

Upon closer inspection, I determined that the F5 was resetting the 
connections, not the server as I had previously thought.  This time, I 
turned off those two options from last year and increased the Maximum 
Segment Retransmissions from the default of 8 to 16.  This controls the 
number of times the F5 resends a packet after it gets no response.  This 
also controls the zero window probes he sends to see if the client can 
receive data yet.  TCP uses a back-off algorithm and increases the time 
between retries.  With 8 attempts, the total retry time is just over a 
minute.  I suspect retries of 16 will cause it to retry for 5 or 10 minutes.


 

I would really like to get this in front of SVN developers, because 
something is getting hosed on the client that causes him to stop pulling 
off the receive buffer.  If the zero window lasted 10 seconds or so, it 
would not be a problem.  But for him to in effect go offline for over a 
minute is, I believe, a bug.  We can just assume that the reason the 
error does not occur when you hit the server directly is that the Su

RE: Error "An existing connection was forcibly closed by the remote host" with F5 content switch or working copy on shared drive

2010-03-17 Thread Bert Huijben
Hi,

 

Subversion uses the neon (or serf) library for connecting with webdav 
repositories. It doesn't change any of the tcp settings itself, nor does it 
handle the tcp connections. (Neither of those has specific MTU handling or 
anything like that as far as I can tell. They just use the self-tuning support 
implemented in the operating system)

 

For the server side everything is handled by the Apache httpd process and our 
mod_dav_svn just receives the pre-parsed requests; so no tcp handling there in 
the Subversion layer either.

 

So I don't think the Subversion project can really fix this for you (as part of 
Subversion). But you might find the developers of the other projects on our 
development list. (Neon, Serf, Neon and Apache Httpd have development lists 
themselves too)

 

Bert

 

From: Justin Johnson [mailto:jus...@honesthacker.com] 
Sent: woensdag 17 maart 2010 12:47
To: users@subversion.apache.org
Subject: Re: Error "An existing connection was forcibly closed by the remote 
host" with F5 content switch or working copy on shared drive

 

On Fri, Mar 12, 2010 at 9:34 AM, Justin Johnson  wrote:

Hi,

I'm trying to understand why the following error occurs.

svn: REPORT request failed on '/svn/reponame/!svn/vcc/default' 
svn: REPORT of '/svn/reponame/!svn/vcc/default': Could not read response body: 
An existing connection was forcibly closed by the remote host.   
(http://HOSTNAME  ) 
command exit code: 1 

I've seen this error in a couple of scenarios:
1) when performing a checkout on a Windows box with the working copy stored on 
a drive mapped to a NAS share
2) when performing a checkout on a Windows box and the server is an F5 content 
switch that just redirects traffic to the Subversion server

The first scenario is of less concern to me, but I mention it anyway since I 
think it is the same problem.

For the second scenario, I worked with someone on our networking team to 
understand the problem.  What he discovered and how he "resolved" it with our 
F5 content switch can be found below.  The server is running Solaris 10, 
Subversion 1.6.6, Apache 2.2.11, and repositories are served via HTTP.  The 
client is running Windows XP SP3 and Subversion 1.6.7 (error occurs with 
TortoiseSVN as well), but the error also occurs on Windows Server 2003.  I 
haven't tested any other Windows client OSes and haven't seen the error on 
UNIX, but suspect the underlying problem may exist there and the OS handles it 
more gracefully.  Here is the explanation by my networking contact.



The problem that is presenting is that the client's receive buffer is filling 
up and staying full for a long period of time.  When this occurs, he advertises 
a tcp window size of 0 in packets he sends to the destination F5.  This also 
happens when he goes directly against a server.  The server seems to tolerate 
it while the F5 does not.  

 

Last year,  I took traces of the traffic against the server by the client 
directly, and through the F5, and saw that the server was seeing different MTU 
and options from the F5.   I modified the standard TCP profile on the F5 to 
have it proxy the TCP options the client offered so the server would get them.  
I also set it to proxy the MTU setting the client offered. This seemed to have 
fixed the problem at that time.  But your current testing failed.  

 

Upon closer inspection, I determined that the F5 was resetting the connections, 
not the server as I had previously thought.  This time, I turned off those two 
options from last year and increased the Maximum Segment Retransmissions from 
the default of 8 to 16.  This controls the number of times the F5 resends a 
packet after it gets no response.  This also controls the zero window probes he 
sends to see if the client can receive data yet.  TCP uses a back-off algorithm 
and increases the time between retries.  With 8 attempts, the total retry time 
is just over a minute.  I suspect retries of 16 will cause it to retry for 5 or 
10 minutes.

 

I would really like to get this in front of SVN developers, because something 
is getting hosed on the client that causes him to stop pulling off the receive 
buffer.  If the zero window lasted 10 seconds or so, it would not be a problem. 
 But for him to in effect go offline for over a minute is, I believe, a bug.  
We can just assume that the reason the error does not occur when you hit the 
server directly is that the Sun box handles the  zero window issue differently, 
or it might just retry more than 8 times by default.  Might be a question for 
the UNIX team as to the retry count.  If we get some time, we could do some 
packet captures and find out for certain.

 

Yesterday and today, I did a few other things that did not help.  I increased 
the TCP receive buffers on the client side sessions, then on the server side 
sessions, then both.  I then turned off all of the tcp options in the F5 
default TCP profile.


S

Re: Error "An existing connection was forcibly closed by the remote host" with F5 content switch or working copy on shared drive

2010-03-17 Thread Justin Johnson
On Fri, Mar 12, 2010 at 9:34 AM, Justin Johnson wrote:

> Hi,
>
> I'm trying to understand why the following error occurs.
>
> svn: REPORT request failed on '/svn/reponame/!svn/vcc/default'
> svn: REPORT of '/svn/reponame/!svn/vcc/default': Could not read response
> body: An existing connection was forcibly closed by the remote host.   (
> http://HOSTNAME )
> command exit code: 1
>
> I've seen this error in a couple of scenarios:
> 1) when performing a checkout on a Windows box with the working copy stored
> on a drive mapped to a NAS share
> 2) when performing a checkout on a Windows box and the server is an F5
> content switch that just redirects traffic to the Subversion server
>
> The first scenario is of less concern to me, but I mention it anyway since
> I think it is the same problem.
>
> For the second scenario, I worked with someone on our networking team to
> understand the problem.  What he discovered and how he "resolved" it with
> our F5 content switch can be found below.  The server is running Solaris 10,
> Subversion 1.6.6, Apache 2.2.11, and repositories are served via HTTP.  The
> client is running Windows XP SP3 and Subversion 1.6.7 (error occurs with
> TortoiseSVN as well), but the error also occurs on Windows Server 2003.  I
> haven't tested any other Windows client OSes and haven't seen the error on
> UNIX, but suspect the underlying problem may exist there and the OS handles
> it more gracefully.  Here is the explanation by my networking contact.
>
> 
> The problem that is presenting is that the client's receive buffer is
> filling up and staying full for a long period of time.  When this occurs, he
> advertises a tcp window size of 0 in packets he sends to the destination
> F5.  This also happens when he goes directly against a server.  The server
> seems to tolerate it while the F5 does not.
>
> Last year,  I took traces of the traffic against the server by the client
> directly, and through the F5, and saw that the server was seeing different
> MTU and options from the F5.   I modified the standard TCP profile on the F5
> to have it proxy the TCP options the client offered so the server would get
> them.  I also set it to proxy the MTU setting the client offered. This
> seemed to have fixed the problem at that time.  But your current testing
> failed.
>
> Upon closer inspection, I determined that the F5 was resetting the
> connections, not the server as I had previously thought.  This time, I
> turned off those two options from last year and increased the Maximum
> Segment Retransmissions from the default of 8 to 16.  This controls the
> number of times the F5 resends a packet after it gets no response.  This
> also controls the zero window probes he sends to see if the client can
> receive data yet.  TCP uses a back-off algorithm and increases the time
> between retries.  With 8 attempts, the total retry time is just over a
> minute.  I suspect retries of 16 will cause it to retry for 5 or 10 minutes.
>
> I would really like to get this in front of SVN developers, because
> something is getting hosed on the client that causes him to stop pulling off
> the receive buffer.  If the zero window lasted 10 seconds or so, it would
> not be a problem.  But for him to in effect go offline for over a minute is,
> I believe, a bug.  We can just assume that the reason the error does not
> occur when you hit the server directly is that the Sun box handles the  zero
> window issue differently, or it might just retry more than 8 times by
> default.  Might be a question for the UNIX team as to the retry count.  If
> we get some time, we could do some packet captures and find out for certain.
>
> Yesterday and today, I did a few other things that *did not *help.  I
> increased the TCP receive buffers on the client side sessions, then on the
> server side sessions, then both.  I then turned off all of the tcp options
> in the F5 default TCP profile.
> 
>
> So, in summary, my problem is currently "resolved" by increasing the
> Maximum Segment Retransmissions from the default of 8 to 16 on the F5.
> However, as I mentioned above I've seen this problem when connecting
> directly to the Subversion server and storing the working copy on a network
> drive.
>
> Does anyone have any ideas?  Is this something that can be fixed in the
> Subversion code itself?
>
> Thanks.
> Justin
>
>
No responses?  This seems like something more for the dev list, but I wanted
to follow protocol and wait for a response from the users list first.

Thanks.
Justin


Re: Cannot accept 'svn:sync-lock' property because it is not encoded in UTF-8

2010-03-17 Thread Daniel Shahaf
svn:sync-lock is set by svnsync as follows:

  apr_err = apr_gethostname(hostname_str, sizeof(hostname_str), pool);
...
  mylocktoken = svn_string_createf(pool, "%s:%s", hostname_str,
   svn_uuid_generate(pool));
...
  /* Except in the very last iteration, try to set the lock. */
  SVN_ERR(svn_ra_change_rev_prop(session, 0, SVNSYNC_PROP_LOCK,
 mylocktoken, subpool));

I suppose either _gethostname() or _uuid_generate() return a non-UTF-8 
string for you.

For the short term, you could either change the hostname (assuming that's 
the problem) or hack svnsync so it generates the lock token differently.  
For the long term, we'll have to make sure the 'mylocktoken' is always 
valid UTF-8. (e.g., what is the encoding of hostname_str?)

Daniel

Dmitry Savvateev wrote on Wed, 17 Mar 2010 at 12:40 +0300:
> Yes, I know that, but svn:sync-lock is a system property added by
> svnsync during synchronization, to keep the target repository locked.
> How do I re-encode it?
> 
> 2010/3/17 Ryan Schmidt :
> > On Mar 17, 2010, at 00:08, Dmitry Savvateev wrote:
> >
> >> I've ran into the following problem with svnsync on Windows Vista.
> >> I'm trying to mirror a repository from my flash drive to the local
> >> disk, and keep getting the following message:
> >>
> >> svnsync: Cannot accept 'svn:sync-lock' property because it is not
> >> encoded in UTF-8
> >>
> >> What's wrong here? I've been doing the same thing many times before,
> >> on Windows and Linux, and never seen anything like this.
> >
> > Subversion requires properties to be UTF-8. This wasn't enforced before, 
> > but now is, as of Subversion 1.6.something, I think. If you have non-UTF-8 
> > properties on old revisions, you have to re-encode them to UTF-8 manually.
> >
> 


Re: Log excluding svn:mergeinfo changes

2010-03-17 Thread Stefan Sperling
On Tue, Mar 16, 2010 at 05:26:47PM -0700, eg wrote:
> On 3/15/2010 9:12 AM, Stefan Sperling wrote:
> 
> >There is an experimental branch which is aimed at implementing
> >what you need:
> >http://svn.apache.org/repos/asf/subversion/branches/ignore-mergeinfo/BRANCH-README
> >
> >I don't know what the status of this branch is, though.
> >It looks like work on it has been suspended, possibly because
> >Hyrum (who started this branch) is uber-busy with the ongoing
> >working copy implementation re-write and other duties.
> >
> 
> I wonder if that might be a good candidate for a Google summer of
> code project?

Yes! Thanks for pointing that out. (I am looking for gsoc project
ideas but couldn't see the forrest for the trees with this one...)


Re: Cannot accept 'svn:sync-lock' property because it is not encoded in UTF-8

2010-03-17 Thread Dmitry Savvateev
Yes, I know that, but svn:sync-lock is a system property added by
svnsync during synchronization, to keep the target repository locked.
How do I re-encode it?

2010/3/17 Ryan Schmidt :
> On Mar 17, 2010, at 00:08, Dmitry Savvateev wrote:
>
>> I've ran into the following problem with svnsync on Windows Vista.
>> I'm trying to mirror a repository from my flash drive to the local
>> disk, and keep getting the following message:
>>
>> svnsync: Cannot accept 'svn:sync-lock' property because it is not
>> encoded in UTF-8
>>
>> What's wrong here? I've been doing the same thing many times before,
>> on Windows and Linux, and never seen anything like this.
>
> Subversion requires properties to be UTF-8. This wasn't enforced before, but 
> now is, as of Subversion 1.6.something, I think. If you have non-UTF-8 
> properties on old revisions, you have to re-encode them to UTF-8 manually.
>