Re: RedirectMatch Question

[Jim]

On Jun 23, 4:58 pm, "Williams, James P2 (N-USA)"
 wrote:
> I don't know the details but have seen Apache config files that
> included something like these lines.
>
>    # workaround for authz and SVNListParentPath issue
>    RedirectMatch ^(/svn)$ $1/
>
> Here's an example.
>
>    http://directory.fedoraproject.org/wiki/Howto:Subversion_Apache_LDAP
>
> I think this just ensures URLs end in a trailing slash.  Does
> whatever "issue" this was trying to fix still exist?  How can I
> tell if I need to do this in my Apache config?

I'm still looking for an answer to this, but found a little more here,

   http://blogs.open.collab.net/svn/subversion_server/

Here's the relevant quote.

"SVNListParentPath and Subversion's authz
One of the first problems people run into when building an Apache-
based Subversion server is when they want to have mod_dav_svn serve a
list of repositories. Everything works fine until they enable
Subversion's authorization (authz) support. What happens is the server
will be configured properly and secured properly but when you go to
the repository collection list, which in our case is http://localhost/repos,
you are forbidden to view the collection even if you have access.
Well, with the RedirectMatch closer to the top of the configuration,
you fix this issue. How you might be asking and the reason is that
when you enable authz, you must have a trailing slash at the end of
the collection url. With the RedirectMatch, we automatically redirect
urls to the collection listing when there is no trailing slash.
Problem solved."

I'm still not sure if I need it because browsing the parent path seems
to work fine whether I've got the RedirectMatch or not.  So, was the
bug fixed?

I've got more than 60  blocks in my http.conf to give URLs
to as many SVNParentPaths.  I'm trying to eliminate as much variation
among these copies as I can to ease maintenance of this mess (also
using Include, and wishing I had mod_macro).  If I could get rid of
the RedirectMatch, that'd be one less line in each copy.

Thanks,

Jim

Re: RedirectMatch Question

[Jim]

It looks like this issue is already being worked if not fixed by now.

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

Thanks,

Jim

Does svn:externals Support --depth?

[Jim]

I'm trying to use svn:externals to include a directory from repo B in 
working copies of repo A.  I can change only repo A.  The external 
directory is huge, but I want only a few immediate children.  Is there a 
way to get what this implies from svn:externals?

% svn proplist -v .
Properties on '.':
  svn:externals
"-r1346 --depth=immediates" 
http://www.example.com/svn/repoB/hugeDirTree smallDirTree

This is conceptual only.  I can't set the property as shown because of the 
--depth.  Apparently, it accepts only a -r.

Thanks.

Jim

Using Hooks To OCR Documents

[Jim Jenkins]

Hi, 

 

I'm planning to use Hooks to add OCR scanning for select documents going
into a SVN repo.  I'm not really sure where to start so I'm hoping
someone here can tell me if it's possible and even suggest how best to
proceed.

 

Basically I'd like to have every commit to an SVN repo stop at the
pre-commit (or another more suitable) hook so the submitted files can be
inspected and if needed run through a command line OCR engine.  We are
dealing with "image" based PDF files so these would be sent off to the
OCR engine and a "test+image" PDF would be returned.  The new PDF would
replace the original before being sent on it's way into the SVN repo.

 

Jim


Jim Jenkins 
Technology Manager
Homrich Berg
3060 Peachtree Road
Suite 830
Atlanta, GA  30305
Phone: 404-264-1400
Fax: 404-237-5114
j...@homrichberg.com
www.homrichberg.com

 

Homrich Berg may review and retain incoming and outgoing electronic mail for 
this e-mail address for quality assurance and regulatory compliance purposes.  
Your transmission of electronic mail to this address represents your consent to 
two-way communication by Internet e-mail.  Communications via email may be 
privileged, confidential, and protected from disclosure.  If you are not the 
intended recipient, any dissemination, distribution, or copying is strictly 
prohibited.  If you received this message in error, please contact the sender 
by reply email and delete the material from any computer on which it exists. 
Please refrain from forwarding this email.

<><>

Upgrading from 1.6.5 (Fedora) to 1.6.16 (built from source)

[Jim Garrison]

The last version available on the Fedora update site for my system (Fedora 10) 
is 1.6.5, and I need the fixes for Tree Conflict resolution that shipped in 
1.6.6 and later versions.

Is there anything special to upgrading other than building 1.6.16 from source, 
uninstalling the Fedora svn RPM and  hooking up Apache and the repository to 
the new version?

Links page from old subversion.tigris.org site?

[Jim Garrison]

There used to be a page at http://subversion.tigris.org/links.html containing 
links to various 3rd-party tools for subversion, including some web front ends. 
 This page doesn't seem to have made the transition to the ASF site.  The old 
(now non-existent) page is linked from a few places, including a StackOverflow 
answer.  Is 
the list of links still available?

svn mkdir --> Conflict - what can cause this?

[Jim Garrison]

We have an automatic (Hudson) build that runs every night.  It starts by making 
a tag directory into which it will then copy the current build root folder.  
Last night, the mkdir failed:

svn --username [obfuscated] --password [obfuscated] --no-auth-cache mkdir 
--parents http://svn/repos/troux/autobuild/trunk/20110926_233057 -m"create 
autobuild tag directory"

svn: Conflict at '/autobuild/trunk/20110926_233057'

The job was rerun this morning without making any changes and it had no problem 
with the mkdir.  I can guarantee that the directory didn't exist in the 
repository prior to the mkdir command.

The svn server is running on Linux (Fedora 14) and is at version 1.6.16
The client is on Linux (Fedora 14) and is at version 1.6.17

Ideas?

Subversion 1.7.4 dirent_uri.c -- svn_uri_is_canonical returns TRUE for invalid file:/// URIs

[Jim GMail]

Kind reader:

 

As far as I can tell, this does not apply to ISSUES 4099, 3609, or 2028, all of 
which reference svn_uri_is_canonical.

 

The following URIs return TRUE from svn_uri_is_canonical:

 

1) file:///MyHost/path

 

2) file:///C:dir/path

 

3) file:///c=dir/path

 

I believe the problem is with code at or about dirent_uri.c -- line 1795:

 

  /* If this is a file url, ptr now points to the third '/' in

 file:///C:/path. Check that if we have such a URL the drive

 letter is in uppercase. */

  if (strncmp(uri, "file:", 5) == 0 &&

  ! (*(ptr+1) >= 'A' && *(ptr+1) <= 'Z') &&

  *(ptr+2) == ':')

return FALSE;

 

This condition evaluates to FALSE (and does not return FALSE) as soon as 
*(prt+1) is determined to be uppercase.

 

This renders the additional check *(ptr+2) == ':' as moot, but I believe this 
check is also invalid, as demonstrated by URI 3)
above.  If *(ptr+2) != ':' the condition is still FALSE and the routine does 
not return FALSE as it should.

 

I respectfully submit the following correction for your consideration:

 

  if (strncmp(uri, "file:", 5) == 0 &&

  ! (*(ptr+1) >= 'A' && *(ptr+1) <= 'Z' &&

 *(ptr+2) == ':' && *(ptr+3) == '/')

   )

return FALSE;

 

If you concur with my finding of this issue, I welcome hints, pointers, or 
guidance as to the proper way to raise this issue through
proper channels.

 

Thank you for your cycles,

 

Jim O'Leary

Using info2 in perl

[Jim Searle]

I am currently using the perl api info and diff_summarize methods, but
I need to switch to info2 and diff_summarize2 since they support the
'depth' option.  But I can't figure out the correct syntax, does
anyone have an example?

Thanks,
Jim

svndumpfilter and subdirectories

[Jim McCaskey]

Hello all,

I'm hoping I'm just failing to find the correct syntax to Google for this 
question.  I have a repository that I want to fish out a subdirectory and all 
its branches.  For example:

project/trunk/compa
project/trunk/compb
project/trunk/compc

I only want to get compb.  BUT, I also need to get all the branches:

project/branches/b1/compa
project/branches/b1/compb
project/branches/b1/compc

project/branches/b2/compa
project/branches/b2/compb 
project/branches/b2/compc

project/branches/b3/compa 
project/branches/b3/compb
project/branches/b3/compc

In the above, I want all the compb directories.  After some research, I came up 
with this command:

cat nightly.dmp | svndumpfilter --drop-empty-revs --renumber-revs include 
project/trunk/compb project/branches/b1/compb project/branches/b2/compb 
project/branches/b3/compb > compb.dmp

That runs and seems to work.  Then I try to import it.  Hilarity ensues:

svnadmin load /data/svn/test/ < compb.dmp

It fails quite often complaining about not being able to find directories.  
I've read the documentation and have done the painstaking bit of building the 
directories needed by the load.  After a few hours of hacking at it that way, I 
get to success!  Or so I thought.

I get full copies of project/trunk/compb and project/branches/b1/compb.  
However, it turn out that project/branches/b2/compb and 
project/branches/b3/compb don't show up at all.  I can't even find references 
to those branch names in the dmp file.

Researching the history of the repo, the two branches that don't show up are 
simply there because they were copied to the branches as part of the branch 
copy. There are different versions on each branch because the branching was 
done at different times.

I'm a bit stumped at this point how to proceed.  Like I said, I'm guessing that 
this has been dealt with before; my Google judo is just not up finding it.

-Jim

Re: Using info2 in perl

[Jim Searle]

I was able to get info2 working with Daniel's suggestion, but now I
can not get status3 to work.

For the code below I get this error when it tries to run status3:
TypeError in method 'svn_client_status3', argument 4 of type
'svn_wc_status_func2_t'

Seems like it wants me to typecast the subroutine, but not sure how to do that?

$s = SVN::Client->new();
# Standard status
print "Using status:\n";
$s->status("", undef,
   sub{($path, $status) = @_;
   print "$path,$status\n" },
   1, 1, 1, 0);

print "\n\nUsing status3:\n";
$s->status3( "", undef,
 sub{($path, $status) = @_;
 print "$path,$status\n" },
 $SVN::Core::depth_immediates, 1, 1, 0, 1, undef );

Thanks,
Jim

On Wed, Mar 21, 2012 at 5:14 PM, Daniel Shahaf  wrote:
> Jim Searle wrote on Wed, Mar 21, 2012 at 16:03:05 -0700:
>> I am currently using the perl api info and diff_summarize methods, but
>> I need to switch to info2 and diff_summarize2 since they support the
>> 'depth' option.  But I can't figure out the correct syntax, does
>> anyone have an example?
>>
>
> % perl -MSVN::Client -le '$s = SVN::Client->new();
>                          $s->info2( "", 1,"HEAD",
>                                     sub{($target, $info_t, $pool) = @_;
>                                         print "$target: ", $info_t->URL },
>                                     $SVN::Core::depth_infinity, undef )'
> A: file:///tmp/svn/r1/trunk/A
> A/B: file:///tmp/svn/r1/trunk/A/B
> ...
> A/D/H/psi: file:///tmp/svn/r1/trunk/A/D/H/psi
> iota: file:///tmp/svn/r1/trunk/iota
>
> How I built this:
>
> - Follow the docs of the svn_client_info2() C API (in doxygen, or in 
> svn_client.h)
>
> - Drop the ctx parameter
>
> - Drop any baton parameters
>
> - When in doubt about some object --- print it.  ref() and Dumper() help too.
>
> HTH,
>
> Daniel
>
>> Thanks,
>> Jim

Re: Using info2 in perl

[Jim Searle]

Thanks.  Yes, it does look like svn_wc_status_func_t is ifdef'ed out
for perl bindings.  So, I assumed it was an issue with the perl
bindings, and reported it to Alien-SVN, but I was told it needs to be
reported to subversion.

I tried to find if this is a known issue, but can not seem to find
one.  The closest I found was:
http://subversion.tigris.org/issues/show_bug.cgi?id=2646
But that only implements exporting of the functions.  So I filed a new issue:
http://subversion.tigris.org/issues/show_bug.cgi?id=4165

- Jim

On Fri, Apr 20, 2012 at 2:39 PM, Daniel Shahaf  wrote:
> Hmm.  A quick glance at subversion/bindings/swig/svn_wc.i tells me that
> perhaps svn_wc_status_func2_t aren't supported by the Perl bindings?
> (notice the pattern of #ifndef's around svn_wc_status_func_t and
> svn_wc_status_func2_t)
>
> Jim Searle wrote on Fri, Apr 20, 2012 at 14:21:52 -0700:
>> I was able to get info2 working with Daniel's suggestion, but now I
>> can not get status3 to work.
>>
>> For the code below I get this error when it tries to run status3:
>> TypeError in method 'svn_client_status3', argument 4 of type
>> 'svn_wc_status_func2_t'
>>
>> Seems like it wants me to typecast the subroutine, but not sure how to do 
>> that?
>>
>> $s = SVN::Client->new();
>> # Standard status
>> print "Using status:\n";
>> $s->status("", undef,
>>            sub{($path, $status) = @_;
>>                print "$path,$status\n" },
>>            1, 1, 1, 0);
>>
>> print "\n\nUsing status3:\n";
>> $s->status3( "", undef,
>>              sub{($path, $status) = @_;
>>                  print "$path,$status\n" },
>>              $SVN::Core::depth_immediates, 1, 1, 0, 1, undef );
>>
>> Thanks,
>> Jim
>>
>> On Wed, Mar 21, 2012 at 5:14 PM, Daniel Shahaf  wrote:
>> > Jim Searle wrote on Wed, Mar 21, 2012 at 16:03:05 -0700:
>> >> I am currently using the perl api info and diff_summarize methods, but
>> >> I need to switch to info2 and diff_summarize2 since they support the
>> >> 'depth' option.  But I can't figure out the correct syntax, does
>> >> anyone have an example?
>> >>
>> >
>> > % perl -MSVN::Client -le '$s = SVN::Client->new();
>> >                          $s->info2( "", 1,"HEAD",
>> >                                     sub{($target, $info_t, $pool) = @_;
>> >                                         print "$target: ", $info_t->URL },
>> >                                     $SVN::Core::depth_infinity, undef )'
>> > A: file:///tmp/svn/r1/trunk/A
>> > A/B: file:///tmp/svn/r1/trunk/A/B
>> > ...
>> > A/D/H/psi: file:///tmp/svn/r1/trunk/A/D/H/psi
>> > iota: file:///tmp/svn/r1/trunk/iota
>> >
>> > How I built this:
>> >
>> > - Follow the docs of the svn_client_info2() C API (in doxygen, or in 
>> > svn_client.h)
>> >
>> > - Drop the ctx parameter
>> >
>> > - Drop any baton parameters
>> >
>> > - When in doubt about some object --- print it.  ref() and Dumper() help 
>> > too.
>> >
>> > HTH,
>> >
>> > Daniel
>> >
>> >> Thanks,
>> >> Jim

RE: Apache Subversion 2.2

[Jim Ravagno]

Hi,
I'm stuck with Windows 2003 server because of the budget.
I would have rather put this on a Solaris OS but that's what I have to work 
with, My second choice was Windows 2008 R2, but again I'm stuck with
2003. 

When I get back to work on Tuesday I'm wiping out everything and starting
over.
Subversion Edge was suggested to me so I'm going with that. 
Hopefully the doc.'s are in the program.

Thank you,

Jim

-Original Message-
From: Nico Kadel-Garcia [mailto:nka...@gmail.com] 
Sent: Friday, August 31, 2012 5:25 PM
To: jrava...@comcast.net
Cc: users@subversion.apache.org
Subject: Re: Apache Subversion 2.2

On Fri, Aug 31, 2012 at 9:27 AM,   wrote:
> Hi,
>
> I was asked to install a source control site for Engineering. They 
> asked for Subversion.
>
>
>
> This is a Rat Hole I didn't want to go down, not only to mention the 
> documention is horrible.

Why is it a rat hole?

> Apache 2.2> Tortoise> WebSVN> PHP 4.3.0. and now Wix installer on 
> Windows
> 2003 Server.

Well, there's a lot of your problem, right there. 2003 is seriously out of
date, and you seem to have  trail of requirements, such as WebSVN, any one
of which may create integration problems. Having to mix and match and merge
these is when and why you can call of of the commercial support companies,
such as CollabNet or WanDisco, to help get the whole thing integrated for
you.

> Does anybody out there have this install guide in a format that's 
> understandable?

Which Subversion release, and which Windows compatible Apache?

>
> I need to have this web accessable, it works great as a stand alone.
>
>
>
> Jim R.

RE: Apache Subversion 2.2

[Jim Ravagno]

Nico,
CollabNet has subversion edge.


 http://www.collab.net/products/subversion

I'll let everyone know how I make out.

I'd like to Thank Dave Anastasio for all his help.

Jim R.


-Original Message-
From: Nico Kadel-Garcia [mailto:nka...@gmail.com] 
Sent: Saturday, September 01, 2012 11:01 AM
To: Jim Ravagno
Cc: users@subversion.apache.org
Subject: Re: Apache Subversion 2.2

On Sat, Sep 1, 2012 at 8:54 AM, Jim Ravagno  wrote:
> Hi,
> I'm stuck with Windows 2003 server because of the budget.
> I would have rather put this on a Solaris OS but that's what I have to 
> work with, My second choice was Windows 2008 R2, but again I'm stuck 
> with 2003.

OK, you just made me giggle. Solaris has to be considered legacy, at this
point: since Oracle bought Sun, they're pushing customers towards Linux,
particularly Oracle's rebuild of Red Hat Enterprise Linux, as quickly as
possible. You'd be out of the frying pan and into the fire that way.

RHEL works well, and is very stable for servers. There are free rebuilds of
it, particularly the very well integrated Scientific Linux, if you're
feeling budget conscious. SL 6.3 comes with Subversion 1.6.11 and is quite
stable.

If you want the latest/greatest Subversion for that distro, the RPMforge
repository is about to include Subversion 1.7.6 from my published tools at
http://github.com/nkadel/. Or you can test invest in commercial support from
Wandisco or CollabNet (and test their free downloads for RHEL, which work
very well.)

>
> When I get back to work on Tuesday I'm wiping out everything and 
> starting over.
> Subversion Edge was suggested to me so I'm going with that.
> Hopefully the doc.'s are in the program.

Good luck with that: it's not a toolkit I've used. The hard part. for me,
has been negotiating and implementing account management and workflow, which
are not really inherent in Subversion itself. There are so *many* options,
I'm encouring the commercial packages (such as WanDisco or CollabNet) for
server setups.

> Thank you,
>
> Jim
>
> -Original Message-
> From: Nico Kadel-Garcia [mailto:nka...@gmail.com]
> Sent: Friday, August 31, 2012 5:25 PM
> To: jrava...@comcast.net
> Cc: users@subversion.apache.org
> Subject: Re: Apache Subversion 2.2
>
> On Fri, Aug 31, 2012 at 9:27 AM,   wrote:
>> Hi,
>>
>> I was asked to install a source control site for Engineering. They 
>> asked for Subversion.
>>
>>
>>
>> This is a Rat Hole I didn't want to go down, not only to mention the 
>> documention is horrible.
>
> Why is it a rat hole?
>
>> Apache 2.2> Tortoise> WebSVN> PHP 4.3.0. and now Wix installer on 
>> Windows
>> 2003 Server.
>
> Well, there's a lot of your problem, right there. 2003 is seriously 
> out of date, and you seem to have  trail of requirements, such as 
> WebSVN, any one of which may create integration problems. Having to 
> mix and match and merge these is when and why you can call of of the 
> commercial support companies, such as CollabNet or WanDisco, to help 
> get the whole thing integrated for you.
>
>> Does anybody out there have this install guide in a format that's 
>> understandable?
>
> Which Subversion release, and which Windows compatible Apache?
>
>>
>> I need to have this web accessable, it works great as a stand alone.
>>
>>
>>
>> Jim R.
>

svn - one realmstring and multiple usernames

[Jim Thompson]

Greetings!

There may be only one answer, but I'll describe my challenge in case someone 
has a better alternative.

I want to run a script (e.g., from cron and/or launched by a CI tool like 
Hudson) which runs some svn commands.  The tricky part is that the script may 
run svn commands using two repositories.  In my case, the username (and 
password) will be different in the two repos, but they have the same 
realmstring.

Here are examples of what I see in ~trantest/.subversion/auth/svn.simple/xxx

Either:
username
V 26
role_StudentAdmin_trantest

Or:
username
V 30
role_StudentAdmin-cfg_trantest

The trick is that the value of svn:realmstring remains the same... So whichever 
repo I last accessed (via a command line like: svn ls https://... --username 
 --password ) has those credentials overwrite the contents of the file 
(~trantest/.subversion/auth/svn.simple/xxx)

I see in the book:
http://svnbook.red-bean.com/nightly/en/svn.serverconfig.netmodel.html#svn.serverconfig.netmodel.credcache

"Credentials are cached in individual files; if you look inside each file, you 
will see keys and values. The svn:realmstringkey describes the particular 
server realm that the file is associated with"

It seems like we need a different realmstring available for one of the repos, 
in order to get two files generated and saved in 
~trantest/.subversion/auth/svn.simple

I'm not seeing another approach that will let my script access both repos, 
unless I change the script to provide --username and --password for each call 
(very nasty).  Any other ideas?

Thanks,
Jim

Re: Help

[Jim Thompson]

On Apr 19, 2010, at 5:50 PM, Ryan Schmidt wrote:

> 
> On Apr 19, 2010, at 17:39, Ryan Schmidt wrote:
> 
>> On Apr 19, 2010, at 17:04, Omar Ousmane Kadry wrote:
>> 
>>> Not sure if it is the right place for this but I’m looking for a way to 
>>> imitate the cvs behavior when checking out folders.
>>> In cvs:
>>>   cvs co mod1/dir1/dir2/file2
>>>   will result in having:
>>>   mod1/dir1/dir2/file2
>>> 
>>> How can I obtain this hierarchical checkout with SVN?
>> 
>> There isn't anything built into Subversion to do that. You'll have to make 
>> the directories yourself, for example using "mkdir -p".
> 

Maybe I misunderstood the question, but this works for me (with an added 
parameter, the directories are created by checkout)...

svn co https://.../example1/trunk/svn-admin/bin example1/trunk/svn-admin/bin


> Here's a quick unix script "svnco" I wrote which you could use instead of 
> "svn co" to do this. There's no error checking, no handling of special 
> characters (i.e. those that would be percent-encoded in URLs), and maybe 
> other issues, but it shows how it can be done.
> 
> 
> $ cat /path/to/svnco
> #!/bin/bash
> 
> URL="$1"
> 
> MKDIR=mkdir
> SED=sed
> SVN=svn
> 
> REPO_ROOT=$($SVN info "$URL" | $SED -n "s|^Repository Root: ||p")
> PATH_IN_REPO=$(echo "$URL" | $SED "s|^$REPO_ROOT/||")
> $MKDIR -p "$PATH_IN_REPO"
> $SVN co "$URL" "$PATH_IN_REPO"
> 
> 
> $ mkdir test
> $ cd test
> $ /path/to/svnco 
> http://svn.macosforge.org/repository/macports/trunk/dports/devel/subversion
> Atrunk/dports/devel/subversion/files
> Atrunk/dports/devel/subversion/files/patch-path.c.diff
> Atrunk/dports/devel/subversion/files/patch-Makefile.in.diff
> Atrunk/dports/devel/subversion/Portfile
> Checked out revision 66676.
> $ find .
> .
> ./trunk
> ./trunk/dports
> ./trunk/dports/devel
> ./trunk/dports/devel/subversion
> ./trunk/dports/devel/subversion/.svn
> ./trunk/dports/devel/subversion/.svn/all-wcprops
> ./trunk/dports/devel/subversion/.svn/entries
> ./trunk/dports/devel/subversion/.svn/prop-base
> ./trunk/dports/devel/subversion/.svn/prop-base/Portfile.svn-base
> ./trunk/dports/devel/subversion/.svn/props
> ./trunk/dports/devel/subversion/.svn/text-base
> ./trunk/dports/devel/subversion/.svn/text-base/Portfile.svn-base
> ./trunk/dports/devel/subversion/.svn/tmp
> ./trunk/dports/devel/subversion/.svn/tmp/prop-base
> ./trunk/dports/devel/subversion/.svn/tmp/props
> ./trunk/dports/devel/subversion/.svn/tmp/text-base
> ./trunk/dports/devel/subversion/files
> ./trunk/dports/devel/subversion/files/.svn
> ./trunk/dports/devel/subversion/files/.svn/all-wcprops
> ./trunk/dports/devel/subversion/files/.svn/entries
> ./trunk/dports/devel/subversion/files/.svn/prop-base
> ./trunk/dports/devel/subversion/files/.svn/props
> ./trunk/dports/devel/subversion/files/.svn/text-base
> ./trunk/dports/devel/subversion/files/.svn/text-base/patch-Makefile.in.diff.svn-base
> ./trunk/dports/devel/subversion/files/.svn/text-base/patch-path.c.diff.svn-base
> ./trunk/dports/devel/subversion/files/.svn/tmp
> ./trunk/dports/devel/subversion/files/.svn/tmp/prop-base
> ./trunk/dports/devel/subversion/files/.svn/tmp/props
> ./trunk/dports/devel/subversion/files/.svn/tmp/text-base
> ./trunk/dports/devel/subversion/files/patch-Makefile.in.diff
> ./trunk/dports/devel/subversion/files/patch-path.c.diff
> ./trunk/dports/devel/subversion/Portfile
> $
> 
> 
> 
> 
> 

Subversion 1.6 write-through proxy mirroring

[Jim Lord]

Hopefully you can point me in the right direction:

I'm setting up a write-through proxy mirror.  I can run:

svnsync init --source-username svnsystem --source-password $pass  
--sync-username svnsystem --sync-password $pass   file:///data/svn/vtest 
https://versiontest2.divxnetworks.com/svn/vtest

from the slave machine versiontest1

BUT, I can't run:

svnsync init --source-username svnsystem --source-password $pass  
--sync-username svnsystem --sync-password $pass   
https://versiontest1.divxnetworks.com/svn/vtest  file:///data/svn

on the master without getting the error:

svnsync: DAV request failed; it's possible that the repository's 
pre-revprop-change hook either failed or is non-existent
svnsync: At least one property change failed; repository is unchanged
svnsync: Server sent unexpected return value (500 Internal Server Error) in 
response to PROPPATCH request for '/svn/vtest/!svn/bln/0'

The pre-revprop-change hooks exist on both master and slave for the vtest 
repository

I want the mirroring to be a PUSH model from the Master to the Slave instead of 
a PULL model from the slave.  Otherwise, I don't think I can get the 
write-through proxying to work correctly.

I do have these on the slave's httpd configuration files:


DAV svn
SVNPath /data/svn/vtest
SVNMasterURI https://versiontest2.divxnetworks.com/svn/vtest
...


DAV svn
SVNPath /data/svn/vtest
SVNMasterURI https://versiontest2.divxnetworks.com/svn/vtest
...



  DAV svn
  SVNPath /data/svn/vtest
  Order deny,allow
  Deny from all
  # Only let the server's IP address access this Location:
  Allow from 172.16.4.134


Is there something about the apache configuration of the master or slave that 
I'm missing?

The master versiontest2 and slave versiontest1 are configured exactly from the 
same image of a Slackware O/S with http v2.2.13.

Re: Hook to check for a presence of file before committing

[Jim Thompson]

SVN has a pristine copy of the checked-out files along with the working copy.  
When you issue a commit, SVN compares the pristine and the local files and 
_only_ sends the diffs.  So the presence of any file doesn't automatically mean 
that it will be visible in the commit _unless_ it changes every time.

Hope this helps.

Cheers,
Jim

On Aug 31, 2010, at 11:22 AM, Tech Geek wrote:

> >You want to enforce that the developer cannot commit unless they have this 
> >project.xml in >their working copy, though it will never be sent to the 
> >repository.
> That's not true. The project.xml (or whatever file that particular file is) 
> should also be a part of commit.
> 
> I will again repeat my question again since there is so much confusion:
> 
> Can we have a pre-commit (preferred) or post-commit server hook that can 
> check for the presence of a particular file (say project.xml) when the users 
> send their working copy to the server to commit? If the file is present 
> accept the commit (along with that file) else reject the commit.
> 
> I would prefer not to implement this on client side.
> 
> I never thought this would be so complicated.

"svn update --set-depth=exclude" exits prematurely, leaving repo in need of cleanup

[Jim Barry]

When excluding a subtree from the working copy, if any unversioned items 
are present then the svn update command fails silently, leaving the 
working copy locked and requiring cleanup.

This is with version 1.9.4, the current release.

Reproducing the problem is fairly straightforward. Create a new repo (or 
just use an existing one):

$ svnadmin create repo
$ svn checkout file://`pwd`/repo wc
Checked out revision 0.

Add a directory and subdirectory:

$ cd wc
$ mkdir dir
$ mkdir dir/subdir1
$ svn add dir
A dir
A dir/subdir1
$ svn commit -m "Added dir"
Adding dir
Adding dir/subdir1
Committing transaction...
Committed revision 1.

Create another subdirectory, without adding it to the repo:

$ mkdir dir/subdir2

Now, let's exclude "dir" from the working copy:

$ svn update --set-depth exclude dir
D dir/subdir1

OK, so svn says it has deleted "dir/subdir1", but has left "dir" alone. 
Fair enough, as "dir" contains the unversioned item "subdir2". 

But wait - let's take a peek:

$ ls dir
subdir1  subdir2

Huh? What is "subdir1" still doing there? Let's quickly do a regular 
update:

$ svn update
svn: E155037: Previous operation has not finished; run 'cleanup' if it 
was interrupted

Oooh, that's not good! Let's take a closer look:

$ svn status
  L .
  L dir
?   dir\subdir1
?   dir\subdir2

Yikes! Looks like svn bailed out without finishing the job.

This must be a bug, right? Any chance somebody can take a look at it?

Thanks!

Re: "svn update --set-depth=exclude" exits prematurely, leaving repo in need of cleanup

[Jim Barry]

> This must be a bug, right? Any chance somebody can take a look at it?

[... tumbleweed ...]

Anyone? Should I file a bug report?

Thanks

Re: "svn update --set-depth=exclude" exits prematurely, leaving repo in need of cleanup

[Jim Barry]

Branko Čibej writes:
> I can reproduce this with 1.9.4 and trunk ... definitely a bug, only
> dir/subdir2 should be left (since dir/subdir2 is unversioned content of
> dir).

Thanks Brane. Would it be possible for an svn dev to take this on?

By the way, I just checked it with 1.8.16 and everything works as 
expected, so it seems this bug was introduced in 1.9.x.

- Jim

Re: "svn update --set-depth=exclude" exits prematurely, leaving repo in need of cleanup

[Jim Barry]

Branko Čibej wrote:
> Please file a bug with the reproduction script.

OK, the issue number is SVN-4642.

Thanks

When connecting to an https server force use of TLS or SSLv3?

[Garrison, Jim (ETW)]

When svn attempts to connect to an https URL, the underlying protocol
library (openssl?) attempts to start the secure protocol negotiation at
the most basic level, plain SSL.

Unfortunately, I have to connect to a server that requires SSL3 or
TLS1, and refuses to respond to SSL or SSL2.

I've done some troubleshooting using s_client and confirmed that if I
let s_client start with the default protocol the server never responds
to the CLIENT HELLO:

$ openssl s_client -connect server.domain.com:443
CONNECTED(0003)
write:errno=104
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 320 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---


Watching this in Wireshark I see:


ClientServer
---syn-->
<--ack---
---CLIENT HELLO->
<--ack---
  [60 second pause]
<--rst---

If I tell s_client to use ssl2 the server immediately closes the
connection. Only ssl3 and tls1 work.

Is there any way to tell subversion to tell the underlying ssl
libraries to skip SSL and SSL2, and start the negotiation with TLS or
SSL3?  I've looked for an OpenSSL config file, but that seems to
control only certificate generation.

Newer SSL libraries and TLSv1.2 incompatibilities

[Garrison, Jim (ETW)]

Regarding my question in the thread titled "When connecting to an https server 
force use of TLS or SSLv3?".

I asked that before I fully understood the problem, which is actually due to a 
backwards incompatibility in the newest OpenSSL libraries (1.0.1c) used by 
Subversion.  Essentially, the newest client library can cause older servers to 
hang when it sends a TLSv1.2 handshake.

The release notes for OpenSSL 1.0.1c contain (changes between 1.0.1 and 1.0.1a):

  *) Workarounds for some broken servers that "hang" if a client hello
 record length exceeds 255 bytes.

 1. Do not use record version number > TLS 1.0 in initial client
hello: some (but not all) hanging servers will now work.
 2. If we set OPENSSL_MAX_TLS1_2_CIPHER_LENGTH this will truncate
the number of ciphers sent in the client hello. This should be
set to an even number, such as 50, for example by passing:
-DOPENSSL_MAX_TLS1_2_CIPHER_LENGTH=50 to config or Configure.
Most broken servers should now work.
 3. If all else fails setting OPENSSL_NO_TLS1_2_CLIENT will disable
TLS 1.2 client support entirely.

Is there any way, other than completely rebuilding svn locally, to use these 
workarounds?

RE: Newer SSL libraries and TLSv1.2 incompatibilities

[Garrison, Jim (ETW)]

> -Original Message-
> From: Garrison, Jim (ETW) [mailto:jim.garri...@nike.com]
> Sent: Wednesday, June 13, 2012 3:56 PM
> To: users@subversion.apache.org
> Subject: Newer SSL libraries and TLSv1.2 incompatibilities
> 
> Regarding my question in the thread titled "When connecting to an https
> server force use of TLS or SSLv3?".
> 
> I asked that before I fully understood the problem, which is actually
> due to a backwards incompatibility in the newest OpenSSL libraries
> (1.0.1c) used by Subversion.  Essentially, the newest client library can
> cause older servers to hang when it sends a TLSv1.2 handshake.
> 
> The release notes for OpenSSL 1.0.1c contain (changes between 1.0.1 and
> 1.0.1a):
> 
>   *) Workarounds for some broken servers that "hang" if a client hello
>  record length exceeds 255 bytes.
> 
>  1. Do not use record version number > TLS 1.0 in initial client
> hello: some (but not all) hanging servers will now work.
>  2. If we set OPENSSL_MAX_TLS1_2_CIPHER_LENGTH this will truncate
> the number of ciphers sent in the client hello. This should be
> set to an even number, such as 50, for example by passing:
> -DOPENSSL_MAX_TLS1_2_CIPHER_LENGTH=50 to config or Configure.
> Most broken servers should now work.
>  3. If all else fails setting OPENSSL_NO_TLS1_2_CLIENT will disable
> TLS 1.2 client support entirely.
> 
> Is there any way, other than completely rebuilding svn locally, to use
> these workarounds?

Please see 
http://rt.openssl.org/Ticket/Display.html?id=2771&user=guest&pass=guest

This is going to cause major headaches for a lot of people.  OpenSSL client 
versions 1.0.1 and later can and will cause earlier server versions to hang at 
CLIENT HELLO.  There are options in the OpenSSL code to tailor the client 
behavior to avoid this, but they require the client applications (i.e. 
subversion) to support setting these options. For example

ctx = SSL_CTX_new(...);
SSL_CTX_set_options(ctx, SSL_OP_NO_TLSv1_2);

What's the possibility of getting an enhancement to subversion to support this 
in its server configuration?

bug Subversion 1.6.15 saslpasswd2.exe does not work

[Christopher Jim Capcom Coleman]

saslpasswd2.exe included with Subversion 1.6.15 does not generate a sasldb
nor does a previously generated sasldb work with the svnserve.exe service
running. I reverted to 1.6.13-r10002845 and saslpasswd2.exe was able to
sucessfully generate sasldb and previously generated sasldb worked with
svnserve.exe service.

saslpasswd2.exe -v on both version state
Built against SASL API version 2.1.23
LibSasl version 2.1.23 by "Cyrus SASL"

regards,
Coleman

RE: [EXTERNAL] Re: svn checkout Hangs/Crashes/Succeeds Over HTTP

[Williams, James P. {Jim} (JSC-CD4)[KBR Wyle Services, LLC] via users]

> This may be a silly question, but has hardware been checked? I would
> start by checking: network wiring to the machine; the machine's RAM.

I don't mind silly; I'm just that desperate.  I'll do what I can to check those 
things, but given that I've seen the same results with the test server on a 
physical machine and a virtual machine, it's probably a long shot.  Both 
machines are pretty quiet, plenty of RAM, disk, and CPU.  And I wouldn't think 
a hardware issue would be resolved by moving to an https://localhost URL.

If I find something awry, I'll post.  Thanks for the suggestion.

Jim

RE: [EXTERNAL] Re: svn checkout Hangs/Crashes/Succeeds Over HTTP

[Williams, James P. {Jim} (JSC-CD4)[KBR Wyle Services, LLC] via users]

I was pulled away from this problem, so I quoted our last exchange.  Daniel, 
you asked to test svn co but keeping communications entirely on the server 
machine.  I did that by using an https://localhost URL.  I also had to turn off 
Kerberos authentication, use "Require all granted", and hide the 
AuthzSVNAccessFile.  I assume Kerberos was failing because the Server Principal 
Name doesn't use localhost, and I assume AuthzSVNAccessFile doesn't work with 
"Require all granted".

With those changes, checkouts consistently succeed to either local disk or an 
NFS mount.  I also don't see core dumps from the client (recall 90% of attempts 
hang, 5% core dump, and 5% succeed).  That sounds like a useful data point, but 
I'm not sure what to do with it.  It points at our network.  My system 
administrators are convinced there's no proxy or reverse proxy.  I expect there 
is security scanning going on, but it's nothing our production server hasn't 
handled fine for many years.  It's also an Apache HTTP server, but uses SVN 
1.9.7.

Thanks for any direction you can give me toward a solution.

Jim

From: Daniel Sahlberg 
Sent: Sunday, June 2, 2024 10:04 AM
Den mån 27 maj 2024 kl 14:18 skrev Johan Corveleyn 
mailto:jcor...@gmail.com>>:
On Sat, May 25, 2024 at 12:12 AM Williams, James P. {Jim}
(JSC-CD4)[KBR Wyle Services, LLC] via users
mailto:users@subversion.apache.org>> wrote:
>
> > Den lör 11 maj 2024 kl 03:00 skrev Williams, James P. {Jim} (JSC-CD4)[KBR 
> > Wyle Services, LLC] via users 
> > mailto:users@subversion.apache.org>>:
>
> > You previously mentioned Subversion 1.14.1, is that on the server or on the 
> > client?
>
> I'm using 1.14.1 on both the client and server.
>
> > Still it would be interesting to compare just to rule out a problem within 
> > the repository. You can use svnserve directly or tunneled over SSH, see the 
> > Subversion book:
>
> With svnserve 1.14.1, I see no problems.  Checkouts complete every time.  I'm 
> not sure what to conclude about that.  It's a different protocol, so it 
> doesn't necessarily exonerate the client or the network.
>
> > >   #0  epoll_wait   /usr/lib64/libc.so.6
>
> > Waiting for a reply from the server ... ?
>
> Yeah, that'd be my guess.  When the hang occurs, I've got about 90% of the 
> working copy checked out.  I expect the client is waiting for more bytes to 
> arrive on the socket.
>
> > Do you see any activity on the server (CPU / disk) during this time?
>
> The server is well-behaved throughout all of my tests.  It shows no CPU spike 
> or log messages hinting that it's noticed a problem.

That's why my bet is still on "something between client and server"
(proxy, reverse-proxy, security scanning soft, ...) that messes with
the network transfer (http or https). That would explain the symptoms
you're seeing (client hangs waiting for network (and sometimes
crashes), server has nothing to do and doesn't report anything
special).

I agree with Johan and I understand it might be hard to nail down the actual 
issue.

I don't think I have asked this before:
- Can you log in to the server and do an svn checkout 
https://localhost/[..<https://localhost/%5b..>.] locally and does this succeed? 
You might have to update the Apache HTTPD configuration to allow the vhost to 
reply to "localhost" (or you could add the server name to the local hosts file 
pointing to 127.0.0.1 and do a checkout of 
https://[server]/[url<https://[server]/%5burl>]). What I'd like to accomplish 
is a checkout that doesn't leave the machine. Does this make a difference?

Kind regards,
Daniel

svn checkout Hangs/Crashes/Succeeds Over HTTP

[Williams, James P. {Jim} (JSC-CD4)[KBR Wyle Services, LLC] via users]

nux)

Server built:   Aug 30 2023 11:01:53

Server's Module Magic Number: 20120211:83

Server loaded:  APR 1.6.3, APR-UTIL 1.6.1

Compiled using: APR 1.6.3, APR-UTIL 1.6.1

Architecture:   64-bit

Server MPM: worker

  threaded: yes (fixed thread count)

forked: yes (variable process count)

Server compiled with

-D APR_HAS_SENDFILE

-D APR_HAS_MMAP

-D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)

-D APR_USE_SYSVSEM_SERIALIZE

-D APR_USE_PTHREAD_SERIALIZE

-D SINGLE_LISTEN_UNSERIALIZED_ACCEPT

-D APR_HAS_OTHER_CHILD

-D AP_HAVE_RELIABLE_PIPED_LOGS

-D DYNAMIC_MODULE_LIMIT=256

-D HTTPD_ROOT="/etc/httpd"

-D SUEXEC_BIN="/usr/sbin/suexec"

-D DEFAULT_PIDLOG="run/httpd.pid"

-D DEFAULT_SCOREBOARD="logs/apache_runtime_status"

-D DEFAULT_ERRORLOG="logs/error_log"

-D AP_TYPES_CONFIG_FILE="conf/mime.types"

-D SERVER_CONFIG_FILE="conf/httpd.conf"

  *   Access to this server from a browser with SVN and ViewVC pages seems to 
work.
  *   Authentication is over Kerberos with mod_auth_gssapi.
  *   Authorization uses AuthzSVNAccessFile and an access file.
  *   SSL is used with SSLCryptoDevice set to builtin, based on 
this<https://lists.apache.org/thread/zysfq4cb0jkz59p0wkhfm49xwr8lj5to>.
  *   I've tried all three MPMs with no change, based on another post:  
prefork, worker, and event.
  *   We've had Apache running on RedHat 6 with these repos for many years.

I'd be glad to provide additional details or run more tests.  Thanks for any 
ideas you have, and for supporting this software.

Jim

RE: [EXTERNAL] Re: svn checkout Hangs/Crashes/Succeeds Over HTTP

[Williams, James P. {Jim} (JSC-CD4)[KBR Wyle Services, LLC] via users]

> How did you upgrade your server from RHEL 6 to RHEL 8?

Because so much changed from RHEL 6 to 8, including Apache from 2.2.15 to 
2.4.37, all the Apache modules, etc., I started from the skeleton configuration 
the operating system provides and made mostly the same customizations we had 
for RHEL 6, or modernized them where the docs said things changed.  Mostly, 
that was tweaks to authentication (from LDAP to Kerberos), SSL, and the SVN 
endpoints.  Browser access to all SVN and ViewVC pages seems to work fine.

> Did you run "svnadmin upgrade" on the repo?

I haven't done anything to the repos.  SVN release notes between 1.10 and 1.14 
sounded like it was unnecessary, that a new server could operate on existing 
repos.  Regardless, I just ran "svnadmin upgrade" on these repos.  Some were 
bumped up to version 8, but it seems to have had no effect on the hangs and 
crashes.

> And just how *big* is the repo?

I've tried with multiple repos of different sizes and ages.  The smaller repo I 
mentioned has about 150 files in trunk, mostly 50 KB or smaller, and about 500 
revisions.  A larger repo with the same problems has about 5000 files in trunk 
and 10,000 revisions.

> Does your client setup work with a notably smaller repo?

Yeah, smaller repos are successful on most or all attempts.  The revision count 
seems to matter more than file count.  One with 150 files and 500 revisions 
fails almost every time.  One with 225 files but only 42 revisions succeeds 
almost every time.  All of the files are small, mostly 50 KB or smaller.

> And do the problems happen if you use svn:// rather than https:// ?

I thought svn:// worked only with svnserve, which we don't run.  Are you 
suggesting I try to run it as a test, or that I consider abandoning Apache in 
favor of it?  Yikes; that'd be painful.

I hear you on the HTTP integration.  We have about 2000 repos and a few hundred 
developers.  I've supported that server for at least 15 years, and it hasn't 
been too bad...until now.

Thanks for the reply.

Jim

-Original Message-
From: Nico Kadel-Garcia 
Sent: Friday, May 10, 2024 6:03 PM
To: Williams, James P. {Jim} (JSC-CD4)[KBR Wyle Services, LLC] 

Cc: users@subversion.apache.org
Subject: [EXTERNAL] Re: svn checkout Hangs/Crashes/Succeeds Over HTTP

CAUTION: This email originated from outside of NASA.  Please take care when 
clicking links or opening attachments.  Use the "Report Message" button to 
report suspicious messages to the NASA SOC.




How did you upgrade your server from RHEL 6 to RHEL 8? Did you run
"svnadmin upgrade" on the repo?  And just how *big* is the repo? Does
your client setup work with a notably smaller repo? And do the
problems happen if you use svn:// rather than https:// ? Because I've
been dealing with Subversion for a long time, and I have up on the
httpd integration years ago, The complex integration with an
overmuscled and constantly evolving, feature evolving webserver was
not something I bother with anymore, and it has big problems with big
repos, including its own repo over at http://svn.apache.org/repos/asf,
which can't be reliably synced anymore because it's gotten so large.

On Fri, May 10, 2024 at 4:17 PM Williams, James P. {Jim} (JSC-CD4)[KBR
Wyle Services, LLC] via users  wrote:
>
> I'm upgrading an Apache HTTP server of our SVN repos on RedHat Enterprise 
> Linux 8.  Using Subversion 1.14.1, svn checkout of even a small, simple repo 
> with about 150 files hangs about 90% of the time, crashes 5%, and succeeds 
> 5%.  Given enough time, the hangs eventually time out after checking out much 
> of the repo.  A debugger shows the following stack during the hang.
>
>
>
>   #0  epoll_wait   /usr/lib64/libc.so.6
>
>   #1  impl_pollset_poll/usr/lib64/libapr-1.so.0
>
>   #2  serf_context_run /usr/lib64/libserf-1.so.0
>
>   #3  svn_ra_serf.context_run  /usr/lib64/libsvn_ra_serf-1.so.0
>
>   #4  finish_report/usr/lib64/libsvn_ra_serf-1.so.0
>
>   #5  svn_wc_crawl_revisions5  /usr/lib64/libsvn_wc-1.so.0
>
>   #6  update_internal.isra /usr/lib64/libsvn_client-1.so.0
>
>   #7  svn_client.update_internal   /usr/lib64/libsvn_client-1.so.0
>
>   #8  svn_client.checkout_internal /usr/lib64/libsvn_client-1.so.0
>
>   #9  svn_client_checkout3 /usr/lib64/libsvn_client-1.so.0
>
>   #10 svn_cl.checkout
>
>   #11 sub_main
>
>   #12 main
>
>
>
> strace shows repeated calls to epoll_wait about 1 sec apart.
>
>
>
> When the checkout crashes, it's a SIGSEGV with this stack,
>
>
>
>   #0  apr_pool_create_ex(libapr-1.so.0)
>
>   #1  svn_pool_create_ex(libsvn_subr-1.so.0)
>

RE: [EXTERNAL] Re: svn checkout Hangs/Crashes/Succeeds Over HTTP

[Williams, James P. {Jim} (JSC-CD4)[KBR Wyle Services, LLC] via users]

> From: Nico Kadel-Garcia 
> Sent: Saturday, May 11, 2024 10:47 AM
> > > How did you upgrade your server from RHEL 6 to RHEL 8?
> >
> > Because so much changed from RHEL 6 to 8, including Apache from 2.2.15
> to 2.4.37, all the Apache modules, etc., I started from the skeleton
> configuration the operating system provides and made mostly the same
> customizations we had for RHEL 6, or modernized them where the docs said
> things changed.  Mostly, that was tweaks to authentication (from LDAP to
> Kerberos), SSL, and the SVN endpoints.  Browser access to all SVN and
> ViewVC pages seems to work fine.
> 
> Yeah. Forklift upgrades can be tricky. If I may suggest, segregate the
> httpd running Subversion from one doing *anything* else.

That was my plan too, to gradually strip off fluff and if necessary everything 
but SVN access to the repos.  I'll report back what I find.

> > I've tried with multiple repos of different sizes and ages.  The
> smaller repo I mentioned has about 150 files in trunk, mostly 50 KB or
> smaller, and about 500 revisions.  A larger repo with the same problems
> has about 5000 files in trunk and 10,000 revisions.
> 
> That *hints* at an httpd tuning issue, but I'm not sure. Check the httpd
> logs?

The httpd logs show no signs of a problem.  Success and failure cases look the 
same in the logs.

> > I thought svn:// worked only with svnserve, which we don't run.  Are
> you suggesting I try to run it as a test, or that I consider abandoning
> Apache in favor of it?  Yikes; that'd be painful.
> 
> I'm suggesting you at least run it as a test, to validate that your
> server's file systems and associated hardware are not messed up and
> hiding some deeper issue. Switch only if you need to. If that's too
> much work, you might try simply doing a file:/// based clone on the
> server itself..

Good ideas.  I'll try svnserve if my pared-down httpd configuration is 
inconclusive.  The same checkouts using file:// URLs are consistently 
successful.  That's not realistic for us, but it's still a useful data point, 
another indication the hangs are somehow in my server or network configuration. 
 The core dumps are still an SVN client problem, but may need whatever that 
wonkiness is to be tickled.

Jim

RE: [EXTERNAL] Re: svn checkout Hangs/Crashes/Succeeds Over HTTP

[Williams, James P. {Jim} (JSC-CD4)[KBR Wyle Services, LLC] via users]

> > > > I've tried with multiple repos of different sizes and ages.  The
> > > smaller repo I mentioned has about 150 files in trunk, mostly 50 KB
> or
> > > smaller, and about 500 revisions.  A larger repo with the same
> problems
> > > has about 5000 files in trunk and 10,000 revisions.
> > >
> > > That *hints* at an httpd tuning issue, but I'm not sure. Check the
> httpd
> > > logs?
> >
> > The httpd logs show no signs of a problem.  Success and failure cases
> look the same in the logs.
> 
> In your initial post your mentioned:
> 
> >>> svn 1.10.2 was failing the same way before we upgraded to 1.14.1 as
> a possible fix.
> 
> So the problem isn't new after the upgrade.

Agreed.  I see no change in behavior, good or bad, between SVN 1.10.2 and 
1.14.1 for the many tests I've run.

> BTW: as Daniel asked: You previously mentioned Subversion 1.14.1, is
> that on the server or on the client?

I've been testing with SVN 1.14.1 on both the client and server.

> Regardless, since the issue manifests on the client-side by hangs and
> crashes while waiting for / processing data from the server (hangs
> inside libsvn_ra_serf), I'd suggest also to investigate whether there
> is something in between your client and your server that might be
> interfering. A proxy or reverse proxy perhaps? Or some security
> software on the client that interferes with the network (as some
> antivirus suites do on Windows)? If so, try to bypass it (or disable /
> create an exclude rule), as a diagnostic step to see whether this
> might be the cause.

I don't think we have anything inserted between client and server, but will ask 
those smarter than me if they know of such a thing.

I do have an update.  My system administrator was surprised to see the server 
machine configured to support both version 4 and 6 IP addresses.  He thought 
the latter were turned off.  After that change, checkouts were noticeably 
faster, and hangs and crashes were noticeably less frequent.  The repo size 
needed to trigger them appeared to grow some.  Though a step forward, the 
configuration still isn't useable.  It might also point at further network 
configuration problems as a cause, though the SVN client probably shouldn't 
crash in any case.

Thanks for the reply.

Jim

RE: [EXTERNAL] [BULK] Re: GUI interface to Subversion via web browser?

[Williams, James P. {Jim} (JSC-CD4)[KBR Wyle Services, LLC] via users]

> > ViewVC 1.2.3 does not support Python 3.
> 
> The fact that their newest release, 1.2.3, still requires python 2 does
> not exactly fill me with confidence with respect to the health of the
> project. :(

For what it's worth, I've been using the latest ViewVC commits along master for 
about a year and have seen no problems.  That's been with Python 3.8 and 3.11 
so far.  I had to ensure some environment variables were exported to CGI 
scripts so ViewVC can find SVN's Python bindings, something like this in the 
server start script,

   export PYTHONPATH=path-to-svn-python-bindings:$PYTHONPATH
   export LD_LIBRARY_PATH=path-to-svn-libs:$LD_LIBRARY_PATH

and this in the server configuration files,

   PassEnv PYTHONPATH LD_LIBRARY_PATH

As simple as that looks, I had to add debugging to ViewVC to figure out why the 
CGI script was having problems, but that has nothing to do with using master 
commits.

Good luck.

Jim

RE: [EXTERNAL] Re: svn checkout Hangs/Crashes/Succeeds Over HTTP

[Williams, James P. {Jim} (JSC-CD4)[KBR Wyle Services, LLC] via users]

> Den lör 11 maj 2024 kl 03:00 skrev Williams, James P. {Jim} (JSC-CD4)[KBR 
> Wyle Services, LLC] via users :
> You previously mentioned Subversion 1.14.1, is that on the server or on the 
> client?

I'm using 1.14.1 on both the client and server.

> Still it would be interesting to compare just to rule out a problem within 
> the repository. You can use svnserve directly or tunneled over SSH, see the 
> Subversion book:

With svnserve 1.14.1, I see no problems.  Checkouts complete every time.  I'm 
not sure what to conclude about that.  It's a different protocol, so it doesn't 
necessarily exonerate the client or the network.

> >   #0  epoll_wait   /usr/lib64/libc.so.6
> Waiting for a reply from the server ... ?

Yeah, that'd be my guess.  When the hang occurs, I've got about 90% of the 
working copy checked out.  I expect the client is waiting for more bytes to 
arrive on the socket.

> Do you see any activity on the server (CPU / disk) during this time?

The server is well-behaved throughout all of my tests.  It shows no CPU spike 
or log messages hinting that it's noticed a problem.

> Memory allocation?

Yeah, both forms of core dumps I've seen have memory/pool allocation at the top 
of the stack.  Maybe some odd reentrancy case is being tickled that's not often 
seen.  It points at a likely secondary problem, a bug in the client.

> Parsing the XML message from the server?
> Can you catch/view the actual XML message sent from the server? I'm thinking 
> if this is mangled in some strange way that is upsetting the XML parser.

We're not able to install tools like wireshark, if that's what you're 
suggesting.  I don't see a way to get to that XML other than doctoring SVN 
source.

> Again something with memory allocation - same here, can you see what the 
> server is actually sending?

Same answer.

> I don't immediately see the call stacks above and the fact that it would fail 
> more often if the WC is on an NFS drive. Possibly if the NFS drive is slower 
> and this causes some kind of timeout? Can you create a ramdisk and have the 
> WC there temporary and see if there is a difference?

I think NFS definitely slows things down, and that change in timing makes the 
hangs and crashes more likely.  Unfortunately, I don't have the access needed 
to create a ramdisk.  I'm able to checkout onto a local or NFS-mounted disk 
though.  I would think the former is equivalent.  No?

Thanks for the reply, Daniel.

Jim

From: Daniel Sahlberg 
Sent: Saturday, May 11, 2024 1:51 PM
To: Williams, James P. {Jim} (JSC-CD4)[KBR Wyle Services, LLC] 

Cc: users@subversion.apache.org
Subject: Re: [EXTERNAL] Re: svn checkout Hangs/Crashes/Succeeds Over HTTP

CAUTION: This email originated from outside of NASA.  Please take care when 
clicking links or opening attachments.  Use the "Report Message" button to 
report suspicious messages to the NASA SOC.


Hi,

I've added a few comments/questions below.

Kind regards,
Daniel Sahlberg

Den lör 11 maj 2024 kl 03:00 skrev Williams, James P. {Jim} (JSC-CD4)[KBR Wyle 
Services, LLC] via users 
mailto:users@subversion.apache.org>>:
> How did you upgrade your server from RHEL 6 to RHEL 8?

Because so much changed from RHEL 6 to 8, including Apache from 2.2.15 to 
2.4.37, all the Apache modules, etc., I started from the skeleton configuration 
the operating system provides and made mostly the same customizations we had 
for RHEL 6, or modernized them where the docs said things changed.  Mostly, 
that was tweaks to authentication (from LDAP to Kerberos), SSL, and the SVN 
endpoints.  Browser access to all SVN and ViewVC pages seems to work fine.

You previously mentioned Subversion 1.14.1, is that on the server or on the 
client?

[...]

> And do the problems happen if you use svn:// rather than https:// ?

I thought svn:// worked only with svnserve, which we don't run.  Are you 
suggesting I try to run it as a test, or that I consider abandoning Apache in 
favor of it?  Yikes; that'd be painful.

I hear you on the HTTP integration.  We have about 2000 repos and a few hundred 
developers.  I've supported that server for at least 15 years, and it hasn't 
been too bad...until now.

I have personally only ever used Subversion over http/https (except for testing 
purposes) and I haven't had any of the problems described by Nico - I guess 
YMMV...

Still it would be interesting to compare just to rule out a problem within the 
repository. You can use svnserve directly or tunneled over SSH, see the 
Subversion book:

https://svnbook.red-bean.com/en/1.7/svn.serverconfig.svnserve.html#svn.serverconfig.svnserve.sshauth


On Fri, May 10, 2024 at 4:17 PM Williams, James P. {Jim} (JSC-CD4)[KBR
Wyle Services, LLC] via users 
mailto:users@subversion.apache.org>> wrote:
>

svnsync Error About Disallowed "non-regular" Property

[Williams, James P. {Jim} (JSC-CD4)[KBR Wyle Services, LLC] via users]

When I run the following on a number of my SVN repos,

   % svnsync initialize file:///my/mirror file:///my/original

I get this error.

   svnsync: E165002: Storage of non-regular property 'svn:entry:committed-date' 
is disallowed
   through the repository interface, and could indicate a bug in your client

I don't know where that property is to remove it or where it came from.  I 
assume it's something SVN puts there for its own bookkeeping.

How do I get past this?

This is with SVN 1.14.1.  Repo formats are all 5.  Just before running svnsync, 
I used "svnadmin create" to create a fresh, empty mirror repo, and added a 
pre-revprop-change hook that just exits.

Thanks for any help you can provide and for supporting SVN.

Jim

RE: [EXTERNAL] Re: svnsync Error About Disallowed "non-regular" Property

[Williams, James P. {Jim} (JSC-CD4)[KBR Wyle Services, LLC] via users]

> From: Andreas Stieger 
> Sent: Friday, August 16, 2024 4:08 AM
> > When I run the following on a number of my SVN repos,
> >
> >% svnsync initialize file:///my/mirror file:///my/original
> >
> > I get this error.
> >
> >svnsync: E165002: Storage of non-regular property
> > 'svn:entry:committed-date' is disallowed
> >
> >through the repository interface, and could indicate a bug in your
> > client
> >
> > I don't know where that property is to remove it or where it came
> > from. I assume it's something SVN puts there for its own bookkeeping.
> >
> > How do I get past this?
> >
> > This is with SVN 1.14.1.  Repo formats are all 5.  Just before running
> > svnsync, I used "svnadmin create" to create a fresh, empty mirror
> > repo, and added a pre-revprop-change hook that just exits.
> >
> 
> Check if your r0 of the source repository has this revision property set
> 
> svnlook proplist --revprop -r 0 REPOS_PATH
> 
> svnlook propget --revprop -r 0 REPO_PATH svn:entry:committed-date
> 
> If it does, you can remove it, see "svnadmin help delrevprop" etc.. That
> should enable the sync to be initialized.

I sort of did that before posting, but results depend on how and where I ask.

   # remote host, http:// finds nothing
   remote-host> svn propget --revprop -r 0 svn:entry:committed-date 
https://my/repo
   svn: E200017: Property 'svn:entry:committed-date' not found on revision 0

   # local host, http:// finds the property
   local-host> svn propget --revprop -r 0 svn:entry:committed-date 
https://my/repo
   1992-01-29T13:14:31.00Z

   # local host, file:// finds the property
   local-host> svn propget --revprop -r 0 svn:entry:committed-date 
file:///my/repo
   1992-01-29T13:14:31.00Z

That's just weird.  Before posting I had run only the first of those.  Any idea 
why the property is visible from one host but not another?

Regardless, you've helped me find a range of revisions that have the property, 
which I can easily remove.

Thanks.

Jim

RE: [EXTERNAL] Re: svnsync Error About Disallowed "non-regular" Property

[Williams, James P. {Jim} (JSC-CD4)[KBR Wyle Services, LLC] via users]

Den fre 16 aug. 2024 kl 18:37 skrev Williams, James P. {Jim} (JSC-CD4)[KBR Wyle 
Services, LLC] via users 
mailto:users@subversion.apache.org>>:
I sort of did that before posting, but results depend on how and where I ask.

   # remote host, http:// finds nothing
   remote-host> svn propget --revprop -r 0 svn:entry:committed-date 
https://my/repo
   svn: E200017: Property 'svn:entry:committed-date' not found on revision 0

   # local host, http:// finds the property
   local-host> svn propget --revprop -r 0 svn:entry:committed-date 
https://my/repo
   1992-01-29T13:14:31.00Z

That is really weird. Are you sure the host "my" actually resolves to the same 
machine on both computers? Are you sure there are no proxies that affect the 
replies (in particular from remote-host)?

There's nothing between these two hosts.  But if there was, wouldn't that be 
even weirder?  Somehow, a proxy decided to hide this particular property, 
coincidentally the one I happen to be having issues with, but let all the 
others go through, unnoticed by the command line client.  It's very repeatable, 
and the command lines are identical for the https://my/repo case.

But I was able to remove the property from a range of revisions and multiple 
repos, so I'm thankful for the help.

Jim