Re: dav_svn__get_inherited_props_report and NetBSD 5.2 install
On 09.07.2013 19:26, Carl Brewer wrote: > > > G'day, > I'm trying to get subversion 1.8 up on a NetBSD 5.2 (amd64) box using > pkgsrc, and am seeing the following at run-time : > > bash-4.2# /etc/rc.d/apache start > Starting apache. > httpd: Syntax error on line 166 of /usr/pkg/etc/httpd/httpd.conf: > Cannot load libexec/mod_dav_svn.so into server: > /usr/pkg/libexec/mod_dav_svn.so: Undefined PLT symbol > "dav_svn__get_inherited_props_report" (symnum = 421) > > > I've asked the pkgsrc people and they're of the opinion that this is a > subversion issue not a pkgsrc issue, so here I am. I've grepped > through the source code and found dav_svn__get_inherited_props_report > in three files : > > subversion-1.8.0/subversion/mod_dav_svn/dav_svn.h > subversion-1.8.0/subversion/mod_dav_svn/reports/inherited-props.c > subversion-1.8.0/subversion/mod_dav_svn/version.c > > > and if I check the freshly built mod_dav_svn.so : > bash-4.2# strings /usr/pkg/libexec/mod_dav_svn.so | grep > dav_svn__get_inherited_props_report > > dav_svn__get_inherited_props_report You could also try: nm /usr/pkg/libexec/mod_dav_svn.so | grep dav_svn__get_inherited_props_report that will, unlike 'strings', tell you if the symbol is actually exported from the shared library. -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
Re: dav_svn__get_inherited_props_report and NetBSD 5.2 install
Branko Čibej writes: > You could also try: > > nm /usr/pkg/libexec/mod_dav_svn.so | grep > dav_svn__get_inherited_props_report > > that will, unlike 'strings', tell you if the symbol is actually exported > from the shared library. Or perhaps "objdump -T" instead of "nm". reports/inherited-props.c is new in 1.8 so if you somehow built the 1.8 mod_dav_svn source code with the 1.7 rules then perhaps that file was not compiled or linked. That would cause warnings about undefined symbols at build time but such warnings are sometimes ignored. -- Philip Martin | Subversion Committer WANdisco | Non-Stop Data www.wandisco.com
Re: dav_svn__get_inherited_props_report and NetBSD 5.2 install
On 10/07/2013 8:42 PM, Philip Martin wrote: Branko Čibej writes: You could also try: nm /usr/pkg/libexec/mod_dav_svn.so | grep dav_svn__get_inherited_props_report that will, unlike 'strings', tell you if the symbol is actually exported from the shared library. Or perhaps "objdump -T" instead of "nm". reports/inherited-props.c is new in 1.8 so if you somehow built the 1.8 mod_dav_svn source code with the 1.7 rules then perhaps that file was not compiled or linked. That would cause warnings about undefined symbols at build time but such warnings are sometimes ignored. That may have happened due to pkgsrc's build setup. I'll bounce this back to the pkgsrc people and see what they think. Thank you Carl
Re: dav_svn__get_inherited_props_report and NetBSD 5.2 install
On 10/07/2013 8:42 PM, Philip Martin wrote: reports/inherited-props.c is new in 1.8 so if you somehow built the 1.8 mod_dav_svn source code with the 1.7 rules then perhaps that file was not compiled or linked. That would cause warnings about undefined symbols at build time but such warnings are sometimes ignored. It looks like it's a problem in pkgsrc's build, thank you for your help. Carl
Re: Expected performance (svn+ssh)
On 2013/07/08 5:10 PM, Thomas Harold wrote: > On 7/8/2013 2:18 PM, Naumenko, Roman wrote: >> >> That box has more than enough CPUs (forty), cores are barely utilized. >> How is the access over ssh can be configured? I thought it's only >> http(s) or svn proto. > http://svnbook.red-bean.com/en/1.7/svn.basic.in-action.html#svn.advanced.reposurls > > > > http://svnbook.red-bean.com/en/1.7/svn.serverconfig.svnserve.html#svn.serverconfig.svnserve.sshtricks > > > > svn+ssh access has some upsides and downsides. For us, it was simpler > to get up and running with it back in 2007 when we were still getting > our feet wet with SVN 1.4. We weren't ready to muck around with > Apache httpd and SSL certificates to do https access to the repository. > > We grant access at the repository level via Linux file system > permissions. This means that every user needs to have their own > system account and belong to Linux group that owns the repository. > > chown -R svn-group1 /var/svn/svn-repository1 > chmod -R 770 /var/svn/svn-repository1 > chmod -R g+s /var/svn/svn-repository1 > > Where the 770 is some combination of, 770, 775, 755, 750, 700. > > 770 = owner read/write, group read/write, other none > 750 = owner read/write, group read-only, other none > > To keep things sane, we do not set permission by hand, but edit a > script that can be re-run to fix permissions on the repositories. Most > of our repositories follow a set naming pattern, which makes it easier. > > The other advantage of svn+ssh is that it works well when using FSVS, > because you can edit ~/.ssh/config so that FSVS can login to the SVN > server automatically and push/pull configuration file changes. Thank you, its interesting. --Roman ___ This email is intended only for the use of the individual(s) to whom it is addressed and may be privileged and confidential. Unauthorised use or disclosure is prohibited. If you receive This e-mail in error, please advise immediately and delete the original message. This message may have been altered without your or our knowledge and the sender does not accept any liability for any errors or omissions in the message. Ce courriel est confidentiel et protégé. L'expéditeur ne renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) désigné(s) est interdite. Si vous recevez ce courriel par erreur, veuillez m'en aviser immédiatement, par retour de courriel ou par un autre moyen.
Re: Expected performance
"Naumenko, Roman" writes: > That box has more than enough CPUs (forty), cores are barely utilized. Subversion's default cache configuration is very conservative. Increasing the cache size can reduce disk IO and improve performance: http://subversion.apache.org/docs/release-notes/1.7.html#server-performance-tuning -- Philip Martin | Subversion Committer WANdisco | Non-Stop Data www.wandisco.com
Re: Expected performance
On 2013/07/10 9:41 AM, Philip Martin wrote: > "Naumenko, Roman" writes: >> That box has more than enough CPUs (forty), cores are barely utilized. > Subversion's default cache configuration is very conservative. > Increasing the cache size can reduce disk IO and improve performance: > > http://subversion.apache.org/docs/release-notes/1.7.html#server-performance-tuning That's one of the options I was looking at. When I checked mem allocation on the server, it appeared that 85% was used as cache, I thought apache process would take advantage of OS caching by default. --Roman Naumenko ___ This email is intended only for the use of the individual(s) to whom it is addressed and may be privileged and confidential. Unauthorised use or disclosure is prohibited. If you receive This e-mail in error, please advise immediately and delete the original message. This message may have been altered without your or our knowledge and the sender does not accept any liability for any errors or omissions in the message. Ce courriel est confidentiel et protégé. L'expéditeur ne renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) désigné(s) est interdite. Si vous recevez ce courriel par erreur, veuillez m'en aviser immédiatement, par retour de courriel ou par un autre moyen.
Re: Expected performance
"Naumenko, Roman" writes: > On 2013/07/10 9:41 AM, Philip Martin wrote: >> "Naumenko, Roman" writes: >>> That box has more than enough CPUs (forty), cores are barely utilized. >> Subversion's default cache configuration is very conservative. >> Increasing the cache size can reduce disk IO and improve performance: >> >> http://subversion.apache.org/docs/release-notes/1.7.html#server-performance-tuning > > That's one of the options I was looking at. When I checked mem > allocation on the server, it appeared that 85% was used as cache, I > thought apache process would take advantage of OS caching by default. It does, but that's caching the on-disk files. The Subversion in-memory cache is for the data structures derived from the files. -- Philip Martin | Subversion Committer WANdisco | Non-Stop Data www.wandisco.com
RE: "svn add *" and sign in filename
> From: 'Daniel Shahaf' [mailto:d...@daniel.shahaf.name] > Sent: Wednesday, July 10, 2013 4:46 AM > > The glob is expanded by the shell, so svn sees ['svn', 'add', 'wc/B/@2.txt'], > so > it parses out target 'wc/B/' with peg '2.txt' (this part is arguably a bug), > and > stripping the slash off the end is normal (see > svn_dirent_canonicalize() in if you're curious). Em.. In fact, I think glob is expanded by the shell on Linux only. ( http://en.wikipedia.org/wiki/Glob_%28programming%29#Implementations ) And it looks like svn "emulates" Linux-style wildcard expansion somehow. Maybe this is what issue 787 is all about. ( http://subversion.tigris.org/issues/show_bug.cgi?id=787 ) One more related discussion: ( http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=236049 ) I understand that making svn behave similar on both platforms is a good idea I don't know how to fix this issue without breaking something else either... It looks like you're right and the safest way for a user is just not to use wildcards at all... I did a quick search through the issue tracker and didn't found anything similar... So, I've just submitted the issue http://subversion.tigris.org/issues/show_bug.cgi?id=4393 . Thanks for your answers!
Re: svn move and sign in filepath
Варфоломеев Игорь wrote on Wed, Jul 10, 2013 at 06:40:39 +0400: > > From: 'Daniel Shahaf' [mailto:d...@daniel.shahaf.name] > > Sent: Wednesday, July 10, 2013 5:45 AM > > > > The question is whether we should not be parsing peg revisions in some > > places. The target arguments to 'add' seem like a clear-cut case. The > > 'dest' > > argument of move seems like such a case too: assuming Q is a versioned > > directory, what would be the meaning of, say, 'svn move alpha beta gamma > > Q@r42'? > > This is not my call, of course, I don't see the whole picture. > But, as for me, it's easier to parse peg revision in all cases. > (And throw error if specifying a revision is not supported) > In this case: > * User-interface is more "uniform". User won't need to remember, whether this > command is able to handle revision each time. > * If you're writing a wrapper for svn, you would need only one "svn_path = > make_svn_path(path,rev)" function. > You won't need to pass any weired additional arguments to it. > * One can imagine, theoretically, that there's a svn command, that is not > supporting revision specification first, > but this functionality might be added in next release. So, in case it > now "parses peg revision" but it was not > parsing it before - some 3rd party scripts might become incompatible. > * It's harder to get unexpected results. > If user is doing something wrong, he would run into an error message, > which is, often, much better that getting unexpected result. > Fair points. I am sure similar points were made on dev@ when the 'svn add foo@' problem was discussed there last year (that's part of the reason I asked you to search for already-filed issues before filing an issue about add: it's possible we decided to followthe semantics you describe, so even 'svn add' targets require peg escaping for consistency). > > Anyway, I don't like the way svn move works with @-files: > Both > svn move wc\@2.txt@ wc\A\@2.txt@ > and > svn move wc\@3.txt@ wc\A\@3.txt > Provide strange results: > "wc\A\@2.txt@" in first case > "wc\a...@3.txt" in second case. > > (see batch file attached) > > But how do I get "wc\A\@4.txt" ? I don't think you can. Please file a bug. Workarounds: - Use copy followed by delete of the source. Problem: in the future we will implement true renames, which are real renames distinct from copy+delete. So that's not a good habit to get into. - Use the bindings to call svn_client_move() directly, bypssing svn's peg revision parsing. Would you be interested in writing patches and/or regression tests for these issues? See https://subversion.apache.org/patches and https://svn.apache.org/repos/asf/subversion/trunk/subversion/tests/cmdline/README
Re: "svn add *" and sign in filename
Варфоломеев Игорь wrote on Wed, Jul 10, 2013 at 20:36:24 +0400:
> > From: 'Daniel Shahaf' [mailto:d...@daniel.shahaf.name]
> > Sent: Wednesday, July 10, 2013 4:46 AM
> >
> > The glob is expanded by the shell, so svn sees ['svn', 'add',
> > 'wc/B/@2.txt'], so
> > it parses out target 'wc/B/' with peg '2.txt' (this part is arguably a
> > bug), and
> > stripping the slash off the end is normal (see
> > svn_dirent_canonicalize() in if you're curious).
>
> Em.. In fact, I think glob is expanded by the shell on Linux only.
> ( http://en.wikipedia.org/wiki/Glob_%28programming%29#Implementations )
> And it looks like svn "emulates" Linux-style wildcard expansion somehow.
> Maybe this is what issue 787 is all about.
> ( http://subversion.tigris.org/issues/show_bug.cgi?id=787 )
> One more related discussion:
> (
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=236049
> )
> I understand that making svn behave similar on both platforms is a good
> idea
> I don't know how to fix this issue without breaking something else either...
> It looks like you're right and the safest way for a user is just not to use
> wildcards at all...
>
> I did a quick search through the issue tracker and didn't found anything
> similar...
> So, I've just submitted the issue
> http://subversion.tigris.org/issues/show_bug.cgi?id=4393 .
>
Sorry, that one is not a valid issue, for the reason I just said: the
wildcard is expanded (by the C runtime) so svn sees 'wc/@2.txt' in argv,
and the error message ("invalid peg") is correct. The recommended
workaround is to append an @ sign to *every* filename or URL you pass on
the svn command line.
BTW: have you tried using --targets? I'm not sure if we parse pegs from
the targets file, so that may fix your moves issue too.
Daniel
> Thanks for your answers!
>
Fwd: [Apache HTTP Server Project: [Announcement] Apache HTTP Server 2.2.25 Released]
- Forwarded message from Apache HTTP Server Project -
> From: "Apache HTTP Server Project"
> Subject: [Announcement] Apache HTTP Server 2.2.25 Released
> To: annou...@subversion.apache.org
> Date: Wed, 10 Jul 2013 12:51:06 -0500
> Message-ID: <20130710125106.6a2eb0d7.wr...@rowe-clan.net>
>
>[Shared with subversion announce for significant mod_dav changes]
>
>Apache HTTP Server 2.2.25 Released
>
>The Apache Software Foundation and the Apache HTTP Server Project are
>pleased to announce the release of version 2.2.25 of the Apache HTTP
>Server ("Apache"). This version of Apache is principally a security
>and bug fix legacy release, including the following security fixes:
>
>* SECURITY: CVE-2013-1896 (cve.mitre.org)
> mod_dav: Sending a MERGE request against a URI handled by
> mod_dav_svn with the source href (sent as part of the request body
> as XML) pointing to a URI that is not configured for DAV will
> trigger a segfault.
>
>* SECURITY: CVE-2013-1862 (cve.mitre.org)
> mod_rewrite: Ensure that client data written to the RewriteLog is
> escaped to prevent terminal escape sequences from entering the
> log file.
>
>The Apache HTTP Project thanks Ben Riser and Ramiro Molina for
>bringing these issues to the attention of the project security team.
>
>Errata: the build is known to fail against OpenSSL when that library
>is built to provide no SSLv2 support whatsoever. The following patch
>will successfully build httpd 2.2.25 against such OpenSSL
>installations:
>
> http://svn.apache.org/viewvc?view=revision&revision=1501712
>
>We consider the Apache HTTP Server 2.4 release to be the best version
>of Apache available, and encourage users of 2.2 and all prior
>versions to upgrade. This 2.2 legacy release is offered for those
>unable to upgrade at this time. For further details, see:
>
> http://www.apache.org/dist/httpd/Announcement2.4.txt
>
>Apache HTTP Server 2.4 and 2.2.25 are available for download from:
>
> http://httpd.apache.org/download.cgi
>
>Please see the CHANGES_2.2 file, linked from the download page, for a
>full list of changes. A condensed list, CHANGES_2.2.25 includes only
>those changes introduced since the prior 2.2 release. A summary of
>all of the security vulnerabilities addressed in this and earlier
>releases is available:
>
> http://httpd.apache.org/security/vulnerabilities_22.html
>
>This release includes the Apache Portable Runtime (APR) version 1.4.8
>and APR Utility Library (APR-util) version 1.5.2, bundled with the
>tar and zip distributions. The APR libraries libapr and libaprutil
>(and on Win32, libapriconv version 1.2.1) must all be updated to
>ensure binary compatibility and address many known security and
>platform bugs. APR-util version 1.5 represents a minor version
>upgrade from earlier httpd 2.2 source distributions.
>
>This release builds on and extends the Apache 2.0 API and is
>superceeded by the Apache 2.4 API. Modules written for Apache 2.0
>or 2.4 will need to be recompiled in order to run with Apache 2.2,
>and most will require minimal or no source code changes.
>
>When upgrading or installing this version of Apache, please bear in
>mind that if you intend to use Apache with one of the threaded MPMs
>(other than the Prefork MPM), you must ensure that any modules you
>will be using (and the libraries they depend on) are thread-safe.
>
- End forwarded message -
Configuring Subversion using SVNSERVE with SASL
Hello All, I have downloaded subversion http://sourceforge.net/projects/win32svn/. We tried to configure subversion using "SVNSERVE utility with SASL" in WIndows XP 32 bit machine. We are able to configure successfully. We created the password database using saslpasswd2 utility. The same is not working withWindows 7 64 bit machine. Here, the saslpasswd2 utility is not creating the password database. Please guide us to configure the subversion using svnserve with SASL support. What i am suspecting is that the setup i have downloaded from the above mentioned url is for 32 bit. I could not find setup for 64 bit. If this is the case please send me the link for 64 bit setup. Regards, Vinoth Kumar S
