Re: SVN commit does nothing

[Les Mikesell]

On Wed, Mar 11, 2015 at 12:32 PM, pascal.sand...@freescale.com
 wrote:
> I'm in a company that use redhat as base distribution. I asked for a web 
> server to migrate some tools from an old server. I asked for recent versions 
> of some tools like php, perl or mysql.
> For this reason (mostly compile a newer version of php) and to be able to put 
> all the binaries and configuration on a storage with backup they gave me a 
> custom web stack compiled with httpd 2.2. Now I have to add svn, that's why I 
> compiled it from source.

> I found that discussion where POST request where not handled by svn. Except I 
> have to error, it seems I face the same kind of problem:

[...]

> How can I trace requests and see where are they handle in httpd?

Does the httpd error_log show a problem?  It could be something simple
like needing to increase apache's setting for LimitRequestBody.  Or
not.

> Should I try to build an older version of svn?

Personally, I've gotten tired of fighting that kind of battle and
would either switch to running svnserve so you don't  have to deal
with apache at all, or find a way to run a stock apache rpm and either
the stock older subversion or a packaged  newer one like wandisco's.
 Is there any chance of getting RHEL7 as your base system?  That
shouldn't be horribly outdated at this point.  You didn't say what
version you have, but mixing httpd 2.2 with new custom stuff seems
like asking for trouble.

-- 
   Les Mikesell
 lesmikes...@gmail.com

RE: SVN commit does nothing

[pascal.sand...@freescale.com]

I don't have any error or warning in httpd error_log.

We are currently using RHEL5.5, it's hard to understand why we are so late in 
upgrading software versions but I can't choose, I have to live with it. But now 
I understand that I should better try to use a global package including all I 
need instead of trying to assemble piece of software.

Do you know which version of svn should I use with httpd2.2?

Pascal

-Original Message-
From: Les Mikesell [mailto:lesmikes...@gmail.com] 
Sent: Wednesday, March 11, 2015 7:01 PM
To: Sandrez Pascal-B09824
Cc: Eric Johnson; users@subversion.apache.org
Subject: Re: SVN commit does nothing

On Wed, Mar 11, 2015 at 12:32 PM, pascal.sand...@freescale.com 
 wrote:
> I'm in a company that use redhat as base distribution. I asked for a web 
> server to migrate some tools from an old server. I asked for recent versions 
> of some tools like php, perl or mysql.
> For this reason (mostly compile a newer version of php) and to be able to put 
> all the binaries and configuration on a storage with backup they gave me a 
> custom web stack compiled with httpd 2.2. Now I have to add svn, that's why I 
> compiled it from source.

> I found that discussion where POST request where not handled by svn. Except I 
> have to error, it seems I face the same kind of problem:

[...]

> How can I trace requests and see where are they handle in httpd?

Does the httpd error_log show a problem?  It could be something simple like 
needing to increase apache's setting for LimitRequestBody.  Or not.

> Should I try to build an older version of svn?

Personally, I've gotten tired of fighting that kind of battle and would either 
switch to running svnserve so you don't  have to deal with apache at all, or 
find a way to run a stock apache rpm and either the stock older subversion or a 
packaged  newer one like wandisco's.
 Is there any chance of getting RHEL7 as your base system?  That shouldn't be 
horribly outdated at this point.  You didn't say what version you have, but 
mixing httpd 2.2 with new custom stuff seems like asking for trouble.

-- 
   Les Mikesell
 lesmikes...@gmail.com

RE: trust-server-cert not behaving as expected

[Madsen, Terry]

This looks like it covers all the bases.  Also (using grep) it looks to provide 
auditability / discoverability in the case of "inherited" systems.  Thank you, 
and looking forward to 1.9!

-Original Message-
From: Stefan Sperling [mailto:s...@elego.de] 
Sent: 10 March, 2015 06:34
To: Branko Čibej
Cc: users@subversion.apache.org; Madsen, Terry
Subject: Re: trust-server-cert not behaving as expected

On Tue, Mar 10, 2015 at 02:07:45PM +0100, Branko Čibej wrote:
> On 10.03.2015 13:59, Madsen, Terry wrote:
> >
> > Thanks for the quick reply!
> >
> >  
> >
> > I agree that this isn't an ideal solution...  however, this is for 
> > an in-house server (with a strong recommendation to use https).  So 
> > the risk of the sort of attack you mention is lower than if it was a 
> > random machine around the net, and TLS isn't really an option.
> >
> >  
> >
> > Would it lessen your concern if a --really-trust-server-cert would 
> > only work if the IP is a non-public one (10.x.x.x, 192.168.x.x, etc)?
> >
> >  
> >
> > Again, though, given that people are already working around this in 
> > ways that seem worse, I'm thinking that this is a matter of "paving 
> > the brown strip in the lawn".
> >
> 
> For an internal server, there's really no good excuse for having an 
> invalid certificate. I can't guess what exactly is invalid about it; 
> one quite likely reason is that it has expired (if it were a valid 
> self-signed cert for the server, for example, --trust-server-cert 
> would be enough).

Agreed. Please get your certificate fixed.
Why even use SSL/TLS if nobody is taking care of certs?

> As to your other argument about there being workarounds: there are 
> always workarounds. For example, you could run a small socket adapter 
> (based on, e.g., Curl or OpenSSL's s_client) that could completely 
> ignore the server certificate and present a plain HTTP connection to 
> your SVN client.

This is beyond the skill and time budget of many of our users, I'm afraid.
Especially those using non-UNIX-based systems.

> IMO, it's better for users to use any kind of workaround than for 
> Subversion to devalue TLS connections by having an option to 
> completely ignore server certificate validity.

FWIW 1.9 will ship with the following new options. They selectively allow users 
to bypass specific certificate validation failures.
But only with --non-interactive, i.e. this is mostly intended for automated 
jobs which might have to be fixed up very quickly even in case a cert has gone 
bad.

  --trust-server-cert  : deprecated; same as --trust-unknown-ca
  --trust-unknown-ca   : with --non-interactive, accept SSL server
 certificates from unknown certificate authorities
  --trust-cn-mismatch  : with --non-interactive, accept SSL server
 certificates even if the server hostname does not
 match the certificate's common name attribute
  --trust-expired  : with --non-interactive, accept expired SSL server
 certificates
  --trust-not-yet-valid: with --non-interactive, accept SSL server
 certificates from the future
  --trust-other-failure: with --non-interactive, accept SSL server
 certificates with failures other than the above

RE: SVN commit does nothing

[pascal.sand...@freescale.com]

Hi

I tried to set “SVNAdvertiseV2Protocol off” and it worked!
It’s something like subversion > 1.6 and httpd 2.2 can’t work properly together.
Finally I compiled subversion 1.6 which is enough for the purpose of this 
installation and that is OK

Thanks a lot for your help!

Pascal


From: Johan Corveleyn [mailto:jcor...@gmail.com]
Sent: Wednesday, March 11, 2015 7:37 PM
To: Sandrez Pascal-B09824
Cc: Eric Johnson; Les Mikesell; users@subversion.apache.org
Subject: RE: SVN commit does nothing


Op 11-mrt.-2015 18:32 schreef 
"pascal.sand...@freescale.com" 
mailto:pascal.sand...@freescale.com>>:
>
> I'm in a company that use redhat as base distribution. I asked for a web 
> server to migrate some tools from an old server. I asked for recent versions 
> of some tools like php, perl or mysql.
> For this reason (mostly compile a newer version of php) and to be able to put 
> all the binaries and configuration on a storage with backup they gave me a 
> custom web stack compiled with httpd 2.2. Now I have to add svn, that's why I 
> compiled it from source.
> I found that discussion where POST request where not handled by svn. Except I 
> have to error, it seems I face the same kind of problem: 
> http://grokbase.com/t/subversion/users/123tdmwx9x/subversion-1-7-server-client-issue-not-able-to-commit-e160013-path-not-found.

That doesn't sound like the same issue to me. That thread mentions a specific 
error message (E160013 path not found) while you said commit just does nothing 
(hangs until timeout or something). Or did you forget to add the tiny detail 
that you got an error ;-) ?

Apart from that, the thread does suggest something to try: did you test if the 
issue goes away if you set "SVNAdvertiseV2Protocol off"?

--
Johan

Re: SVN commit does nothing

[Philip Martin]

Subversion 1.8 works with httpd 2.2.  Something (a module, a proxy, a
load balancer) is interfering with POST requests.  The best solution is
to identify what is interfering with POST and fix it, but if you cannot
do that you are advised to run 1.8 with "SVNAdvertiseV2Protocol off"
rather than 1.6. 1.6 has lower performance, more bugs, and is no longer
supported.

"pascal.sand...@freescale.com"  writes:

> Hi
>
> I tried to set “SVNAdvertiseV2Protocol off” and it worked!
> It’s something like subversion > 1.6 and httpd 2.2 can’t work properly 
> together.
> Finally I compiled subversion 1.6 which is enough for the purpose of
> this installation and that is OK
>
> Thanks a lot for your help!
>
> Pascal
>
>
> From: Johan Corveleyn [mailto:jcor...@gmail.com]
> Sent: Wednesday, March 11, 2015 7:37 PM
> To: Sandrez Pascal-B09824
> Cc: Eric Johnson; Les Mikesell; users@subversion.apache.org
> Subject: RE: SVN commit does nothing
>
>
> Op 11-mrt.-2015 18:32 schreef
> "pascal.sand...@freescale.com"
> mailto:pascal.sand...@freescale.com>>:
>>
>> I'm in a company that use redhat as base distribution. I asked for a
>> web server to migrate some tools from an old server. I asked for
>> recent versions of some tools like php, perl or mysql.
>> For this reason (mostly compile a newer version of php) and to be
>> able to put all the binaries and configuration on a storage with
>> backup they gave me a custom web stack compiled with httpd 2.2. Now
>> I have to add svn, that's why I compiled it from source.
>> I found that discussion where POST request where not handled by
>> svn. Except I have to error, it seems I face the same kind of
>> problem:
>> http://grokbase.com/t/subversion/users/123tdmwx9x/subversion-1-7-server-client-issue-not-able-to-commit-e160013-path-not-found.
>
> That doesn't sound like the same issue to me. That thread mentions a
> specific error message (E160013 path not found) while you said commit
> just does nothing (hangs until timeout or something). Or did you
> forget to add the tiny detail that you got an error ;-) ?
>
> Apart from that, the thread does suggest something to try: did you
> test if the issue goes away if you set "SVNAdvertiseV2Protocol off"?
>
> --
> Johan

-- 
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*

RE: SVN commit does nothing

[pascal.sand...@freescale.com]

I also think that "something" is interfering with this request but I don't know 
how to identify this issues as I don't master these technologies and don't see 
any error.
But thanks, I take note that it would be better to install version 1.8 anyway.
Pascal

-Original Message-
From: Philip Martin [mailto:philip.mar...@wandisco.com] 
Sent: Thursday, March 12, 2015 4:40 PM
To: Sandrez Pascal-B09824
Cc: Johan Corveleyn; Eric Johnson; Les Mikesell; users@subversion.apache.org
Subject: Re: SVN commit does nothing

Subversion 1.8 works with httpd 2.2.  Something (a module, a proxy, a load 
balancer) is interfering with POST requests.  The best solution is to identify 
what is interfering with POST and fix it, but if you cannot do that you are 
advised to run 1.8 with "SVNAdvertiseV2Protocol off"
rather than 1.6. 1.6 has lower performance, more bugs, and is no longer 
supported.

"pascal.sand...@freescale.com"  writes:

> Hi
>
> I tried to set “SVNAdvertiseV2Protocol off” and it worked!
> It’s something like subversion > 1.6 and httpd 2.2 can’t work properly 
> together.
> Finally I compiled subversion 1.6 which is enough for the purpose of 
> this installation and that is OK
>
> Thanks a lot for your help!
>
> Pascal
>
>
> From: Johan Corveleyn [mailto:jcor...@gmail.com]
> Sent: Wednesday, March 11, 2015 7:37 PM
> To: Sandrez Pascal-B09824
> Cc: Eric Johnson; Les Mikesell; users@subversion.apache.org
> Subject: RE: SVN commit does nothing
>
>
> Op 11-mrt.-2015 18:32 schreef
> "pascal.sand...@freescale.com"
> mailto:pascal.sand...@freescale.com>>:
>>
>> I'm in a company that use redhat as base distribution. I asked for a 
>> web server to migrate some tools from an old server. I asked for 
>> recent versions of some tools like php, perl or mysql.
>> For this reason (mostly compile a newer version of php) and to be 
>> able to put all the binaries and configuration on a storage with 
>> backup they gave me a custom web stack compiled with httpd 2.2. Now I 
>> have to add svn, that's why I compiled it from source.
>> I found that discussion where POST request where not handled by svn. 
>> Except I have to error, it seems I face the same kind of
>> problem:
>> http://grokbase.com/t/subversion/users/123tdmwx9x/subversion-1-7-server-client-issue-not-able-to-commit-e160013-path-not-found.
>
> That doesn't sound like the same issue to me. That thread mentions a 
> specific error message (E160013 path not found) while you said commit 
> just does nothing (hangs until timeout or something). Or did you 
> forget to add the tiny detail that you got an error ;-) ?
>
> Apart from that, the thread does suggest something to try: did you 
> test if the issue goes away if you set "SVNAdvertiseV2Protocol off"?
>
> --
> Johan

--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*

Re: SVN commit does nothing

[Les Mikesell]

On Thu, Mar 12, 2015 at 11:59 AM, pascal.sand...@freescale.com
 wrote:
> I also think that "something" is interfering with this request but I don't 
> know how to identify this issues as I don't master these technologies and 
> don't see any error.
> But thanks, I take note that it would be better to install version 1.8 anyway.
> Pascal
>

If you had a stock RHEL5.x apache, I'd recommend starting here:
http://opensource.wandisco.com/rhel/5/svn-1.8/RPMS/.  You might be
able to get the src.rpms to rebuild against what you have, but I think
the apr* part has to match your apache build.

-- 
   Les Mikesell
 lesmikes...@gmail.com

Re: 1.8 bug(?): svn:mergeinfo set for tree-conflicted files in subdirs

[Pete Harlan]

I verified that this test also fails the same way on the latest
subversion trunk (1.10.0-dev).

Pass: 1.6.11
Pass: 1.7.17

Fail: 1.8.11
Fail: 1.10.0-dev

Is there a reason not to open a bug report?

Thanks,

--Pete

On Wed, Mar 11, 2015 at 4:54 PM, Pete Harlan  wrote:
> Thank you for your reply.
>
>> the mergeinfo tells that it didn't merge to that node.
>
> Once I've resolved the tree conflict, is there a sense in which it
> didn't merge everything in /trunk into /branches/branch?  Marking the
> tree conflict resolved doesn't remove the svn:mergeinfo property from
> dir/file.txt, but from my perspective, I've told Subversion how to
> resolve the merge and therefore want it to consider the two branches
> fully merged going forward.
>
> If the behavior is intentional, what is the recommended way to tell
> Subversion that I consider the two paths fully merged?  And is this
> difference meant to be introduced in 1.8 vs. 1.7?  From what I read it
> looked like merge semantics weren't intended to change, just some of
> the client-side bookkeeping.
>
> Thank you for your time,
>
> --Pete
>
> On Wed, Mar 11, 2015 at 4:25 PM, Bert Huijben  wrote:
>> I don’t know whether it is a bug or a feature. Storing this value will make
>> a future merge handle the partial merge that was skipped at first: the
>> mergeinfo tells that it didn't merge to that node.
>>
>> There are two ways to remember that: record ‘non inheritable’ info on the
>> direct parent, and then again on all children that are merged… The untouched
>> node is then unaffected, but future merges will be slower as more nodes have
>> specific merge-info. Storing it just on the node that is not merged as you
>> see here is the other option, which will keep your further merges faster.
>>
>> In 1.6 we could in general not change the node affected by a tree conflict,
>> so we always had to choose the slow option. With the central metadata
>> storage we can do things more efficient… and this allowed fixing a lot of
>> known issues of previous versions.
>>
>> Bert
>> Sent from Windows Mail
>>
>> From: Pete Harlan
>> Sent: ‎Wednesday‎, ‎March‎ ‎11‎, ‎2015 ‎11‎:‎16‎ ‎PM
>> To: 'subversion'
>>
>> Hi,
>>
>> Subversion 1.8.11 behaves differently than 1.7.17 and 1.6.11, in that
>> it sets empty svn:mergeinfo properties for files within a
>> tree-conflicted directory during a merge.  The effect is this:
>>
>> Layout:
>>
>> /trunk
>> /branches/branch
>>
>> Add empty dir/file.txt to trunk and independently to branch.
>> Merge trunk to branch; the resulting merge generates:
>>
>> % svn propget -v svn:mergeinfo -R
>> Properties on '.':
>>   svn:mergeinfo
>> /trunk:2-4
>> Properties on 'dir/file.txt':
>>   svn:mergeinfo
>>
>> %
>>
>> Expected result is that no svn:mergeinfo property would appear on
>> dir/file.txt.  Is this a bug?  A known bug?
>>
>> Thanks,
>> Pete
>>
>> Script to reproduce (run as "script.sh /path/to/svn"):
>>
>> #!/bin/bash
>> #
>> # Reproduce an issue in Subversion 1.8.11 where files in a tree
>> # conflict can have svn:mergeinfo properties added to them during a
>> # merge.
>> set -e
>>
>> SERVER_DIR=server
>> CLIENT_DIR=client
>>
>> if [ $# != 1 ]; then
>> echo "usage: $0 "
>> exit
>> fi
>>
>> SVN=$1
>> SVNADMIN="$(dirname $SVN)/svnadmin"
>>
>> SERVER_URL="file:///$PWD/$SERVER_DIR"
>>
>> createAndCommitSubdirWithFile ()
>> {
>> mkdir dir
>> touch dir/file.txt
>> $SVN add dir
>> $SVN commit -m "$1"
>> $SVN update  # Update . to committed rev
>> }
>>
>> # Create the repo and enter it.
>> $SVNADMIN create $SERVER_DIR
>> $SVN checkout $SERVER_URL $CLIENT_DIR
>> cd $CLIENT_DIR
>>
>> # Create the trunk/branches structure
>> mkdir trunk
>> mkdir branches
>> $SVN add trunk branches
>> $SVN commit -m 'Create initial structure'
>>
>> # Make a branch from the trunk.
>> $SVN copy ^/trunk ^/branches/branch -m 'Create branch from trunk'
>>
>> # Commit a subdir with a file in it in the trunk and commit it.
>> $SVN switch --ignore-ancestry ^/trunk
>> createAndCommitSubdirWithFile 'Committed on trunk'
>>
>> # Commit a subdir with a file in it in the branch and commit it.
>> $SVN switch ^/branches/branch
>> createAndCommitSubdirWithFile 'Committed on branch'
>>
>> # Merge the trunk and display any svn:mergeinfo properties.
>> # (Remove --non-interactive if testing svn prior to 1.7)
>> $SVN merge --non-interactive ^/trunk || true
>> $SVN propget svn:mergeinfo -R . >actual.out
>>
>> echo '. - /trunk:2-4' >expected.out
>>
>> $SVN --version | head -1
>>
>> if diff -q actual.out expected.out; then
>> echo Success
>> else
>> echo 'Test failed!'
>> echo 'Expected output:'
>> cat expected.out
>> echo 'Actual output:'
>> cat actual.out
>> exit 1
>> fi