Re: Subversion compilation
Naumenko, Roman wrote on Tue, Aug 06, 2013 at 19:19:50 +: > Hi, > > Is there something obvious missing during compilation for such error? > > bash-3.2$ /home/userb/svn/bin/svn co http://svnserver/svn/repositoryA/ > /tmp/repoA/ > /home/userb/svn/bin/svn: symbol lookup error: > /home/userb/svn/lib/libsvn_ra_neon-1.so.0: undefined symbol: ne_accept_207 > > Version was 1.7.9, compiled with the following options (it gnored > --without-apache though). > ./configure --without-berkeley-db --without-apache --without-apxs > --without-swig --with-ssl --with-serf=/home/userb/local/serf > --prefix=/home/userb/svn > > I've added path to svn lib in LD > bash-3.2$ ldd /home/userb/svn/bin/svn | grep neon > libsvn_ra_neon-1.so.0 => /home/userb/svn/lib/libsvn_ra_neon-1.so.0 > (0x2b3846cff000) > It appears libneon itself is missing; compare: % ldd /usr/bin/svn | grep neon libsvn_ra_neon-1.so.1 => /usr/lib/libsvn_ra_neon-1.so.1 (0x7f988087c000) libneon-gnutls.so.27 => /usr/lib/libneon-gnutls.so.27 (0x7f987e7d7000) > serf was 0.7.2 and apr was 1.4.5 > serf-0.7 is old, but anyway, things should just work if you use --config-option=servers:global:http-library=serf to your command line.
Re: Proxy error on SVN 1.8.1
Lieven Govaerts wrote on Mon, Aug 05, 2013 at 09:03:13 +0200: > Now I see that homebrew provides serf 1.2.1, also for Subversion 1.8.1 > (*). Serf 1.3.0 is available which includes many fixes for the ssl > tunnel and authentication code. So I propose that you test with serf > 1.3.0 first. You'll have to build svn and serf manually or wait for > the homebrew project to update serf to 1.3.0. Shouldn't it be possible to avoid rebuilding Subversion by installing serf-1.3 on top of serf-1.2? That's the point of shared libraries...
Re: Subversion compilation
Daniel Shahaf writes: >> bash-3.2$ /home/userb/svn/bin/svn co http://svnserver/svn/repositoryA/ >> /tmp/repoA/ >> /home/userb/svn/bin/svn: symbol lookup error: >> /home/userb/svn/lib/libsvn_ra_neon-1.so.0: undefined symbol: ne_accept_207 >> >> Version was 1.7.9, compiled with the following options (it gnored >> --without-apache though). >> ./configure --without-berkeley-db --without-apache --without-apxs >> --without-swig --with-ssl --with-serf=/home/userb/local/serf >> --prefix=/home/userb/svn >> >> I've added path to svn lib in LD >> bash-3.2$ ldd /home/userb/svn/bin/svn | grep neon >> libsvn_ra_neon-1.so.0 => /home/userb/svn/lib/libsvn_ra_neon-1.so.0 >> (0x2b3846cff000) >> > > It appears libneon itself is missing; compare: > > % ldd /usr/bin/svn | grep neon > libsvn_ra_neon-1.so.1 => /usr/lib/libsvn_ra_neon-1.so.1 > (0x7f988087c000) > libneon-gnutls.so.27 => /usr/lib/libneon-gnutls.so.27 > (0x7f987e7d7000) Perhaps neon is static? I seem to recall that building neon defaults to static only unless there is an explict --enable-shared. >> serf was 0.7.2 and apr was 1.4.5 >> > > serf-0.7 is old, but anyway, things should just work if you use > > --config-option=servers:global:http-library=serf > > to your command line. That probably won't help since the linker is failing to load the linked library at program startup. It might work if Subversion was configured with --enable-runtime-module-search. It would be better to fix the libneon problem. -- Philip Martin | Subversion Committer WANdisco | Non-Stop Data
Re: Subversion compilation
On 2013/08/07 6:19 AM, Philip Martin wrote: > Daniel Shahaf writes: >>> bash-3.2$ /home/userb/svn/bin/svn co http://svnserver/svn/repositoryA/ >>> /tmp/repoA/ >>> /home/userb/svn/bin/svn: symbol lookup error: >>> /home/userb/svn/lib/libsvn_ra_neon-1.so.0: undefined symbol: ne_accept_207 >>> >>> Version was 1.7.9, compiled with the following options (it gnored >>> --without-apache though). >>> ./configure --without-berkeley-db --without-apache --without-apxs >>> --without-swig --with-ssl --with-serf=/home/userb/local/serf >>> --prefix=/home/userb/svn >>> >>> I've added path to svn lib in LD >>> bash-3.2$ ldd /home/userb/svn/bin/svn | grep neon >>> libsvn_ra_neon-1.so.0 => /home/userb/svn/lib/libsvn_ra_neon-1.so.0 >>> (0x2b3846cff000) >> It appears libneon itself is missing; compare: >> >> % ldd /usr/bin/svn | grep neon >> libsvn_ra_neon-1.so.1 => /usr/lib/libsvn_ra_neon-1.so.1 >> (0x7f988087c000) >> libneon-gnutls.so.27 => /usr/lib/libneon-gnutls.so.27 >> (0x7f987e7d7000) > Perhaps neon is static? I seem to recall that building neon defaults to > static only unless there is an explict --enable-shared. >>> serf was 0.7.2 and apr was 1.4.5 >> serf-0.7 is old, but anyway, things should just work if you use >> >>--config-option=servers:global:http-library=serf >> >> to your command line. > That probably won't help since the linker is failing to load the linked > library at program startup. It might work if Subversion was configured > with --enable-runtime-module-search. It would be better to fix the > libneon problem. It was indeed absent neon lib (I thought it's part of svn and would be compiled by default). No issues with neon excluded in ./configure (--without-neon). Also I used serf 0.7.2 because this version was used in get-deps.sh for that particular svn version, I guess I can use the latest. --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.
SVN copy that worked in 1.8.0 not fails with (424 Failed Dependency)
svn: E175002: Adding directory failed: COPY on /svn/Development/!svn/rvr/7020/Trunk/Projects/SiteWatch (424 Failed Dependency) This is part of our build process which hasn't changed and worked prior to updating to 1.8.1 yesterday (Visual SVN Server). I tested copying some other paths and that works, the path in question has externals defined which I suspect may have something to do with this? I don't see anything in the release notes that would seem relevant. I'm going to do more testing on my end, try to figure out what happened. Any suggestions? Thanks!
RE: SVN copy that worked in 1.8.0 now fails with (424 Failed Dependency)
> -Original Message- > From: Brenden Walker [mailto:bkwal...@drbsystems.com] > Sent: Wednesday, August 07, 2013 11:27 AM > To: users@subversion.apache.org > Subject: SVN copy that worked in 1.8.0 not fails with (424 Failed Dependency) > > svn: E175002: Adding directory failed: COPY on > /svn/Development/!svn/rvr/7020/Trunk/Projects/SiteWatch (424 Failed > Dependency) > > This is part of our build process which hasn't changed and worked prior to > updating to 1.8.1 yesterday (Visual SVN Server). I tested copying some other > paths and that works, the path in question has externals defined which I > suspect may have something to do with this? > > I don't see anything in the release notes that would seem relevant. > > I'm going to do more testing on my end, try to figure out what happened. > Any suggestions? > > Thanks! Follow up.. I was mistaken on the timing for this, it may have been introduced when we updated to 1.8.0 I can copy many other things, I have it narrowed down to 2 particular paths under the main folder being copied.So far I haven't found anything unusual about these paths, no unusual properties (externals or the like).
Re: xml output changed - relative paths now appearing?
On Tue, Jul 16, 2013 at 6:26 AM, Bert Huijben wrote: > > -Original Message- > > With 1.7 I get > > > > >path="/home/pm/sw/subversion/obj/wc"> > > >path="/home/pm/sw/subversion/obj/wc/foo"> > > > > while with 1.8 I get > > > > >path="/home/pm/sw/subversion/obj/wc"> > > >path="."> > > This appears wrong to me. > svn status always gave the paths in the same form as how the user passed > them, in both non-xml and xml form. > > I would guess that a lot of scripts break down if the paths don't match the > form that they expected from all previous versions. > > I think we should revert to the old form, where the input path dictates the > form in which we provide paths. Certainly for the --xml option, any other > form will break scripts. > So - where does this stand - having an informal list agreement that this is an issue - should I be submitting an issue formally- consider me new to this development model and unsure of "what is the next step" on this. I look forwards to learning, thanks, Alex -- Alexander Haley, Computer Scientist, 781-774-5156 Medical Information Technology, Inc. Mailstop: F4E16W, MEDITECH Circle, Westwood, MA 02090
Re: xml output changed - relative paths now appearing?
Alexander Haley writes: > On Tue, Jul 16, 2013 at 6:26 AM, Bert Huijben wrote: > >> > -Original Message- >> > With 1.7 I get >> > >> > > >path="/home/pm/sw/subversion/obj/wc"> >> > > >path="/home/pm/sw/subversion/obj/wc/foo"> >> > >> > while with 1.8 I get >> > >> > > >path="/home/pm/sw/subversion/obj/wc"> >> > > >path="."> >> >> This appears wrong to me. >> svn status always gave the paths in the same form as how the user passed >> them, in both non-xml and xml form. >> >> I would guess that a lot of scripts break down if the paths don't match the >> form that they expected from all previous versions. >> >> I think we should revert to the old form, where the input path dictates the >> form in which we provide paths. Certainly for the --xml option, any other >> form will break scripts. >> > > So - where does this stand - having an informal list agreement that this > is an issue - should I be submitting an issue formally- consider me new to > this development model and unsure of "what is the next step" on this. It's fixed on trunk: http://subversion.tigris.org/issues/show_bug.cgi?id=4398 -- Philip Martin | Subversion Committer WANdisco | Non-Stop Data
RESOLVED: SVN copy that worked in 1.8.0 now fails with (424 FailedDependency)
> -Original Message- > From: Brenden Walker [mailto:bkwal...@drbsystems.com] > Sent: Wednesday, August 07, 2013 11:42 AM > To: users@subversion.apache.org > Subject: RE: SVN copy that worked in 1.8.0 now fails with (424 > FailedDependency) > > > -Original Message- > > From: Brenden Walker [mailto:bkwal...@drbsystems.com] > > Sent: Wednesday, August 07, 2013 11:27 AM > > To: users@subversion.apache.org > > Subject: SVN copy that worked in 1.8.0 not fails with (424 Failed > > Dependency) > > > > svn: E175002: Adding directory failed: COPY on > > /svn/Development/!svn/rvr/7020/Trunk/Projects/SiteWatch (424 Failed > > Dependency) > > > > This is part of our build process which hasn't changed and worked > > prior to updating to 1.8.1 yesterday (Visual SVN Server). I tested > > copying some other paths and that works, the path in question has > > externals defined which I suspect may have something to do with this? > > > > I don't see anything in the release notes that would seem relevant. > > > > I'm going to do more testing on my end, try to figure out what happened. > > Any suggestions? > > > > Thanks! > > Follow up.. I was mistaken on the timing for this, it may have been > introduced when we updated to 1.8.0 > > I can copy many other things, I have it narrowed down to 2 particular paths > under the main folder being copied.So far I haven't found anything unusual > about these paths, no unusual properties (externals or the like). Turned out that another developer had locks on several files. Confirmed that was the problem. A more specific error message would have been handy here.
Re: RESOLVED: SVN copy that worked in 1.8.0 now fails with (424 FailedDependency)
Brenden Walker writes: >> > svn: E175002: Adding directory failed: COPY on >> > /svn/Development/!svn/rvr/7020/Trunk/Projects/SiteWatch (424 Failed >> > Dependency) > > Turned out that another developer had locks on several files. > Confirmed that was the problem. A more specific error message would > have been handy here. Can you describe how to reproduce the problem? What sort of locks prevent a COPY? Orphaned locks perhaps? -- Philip Martin | Subversion Committer WANdisco | Non-Stop Data
Re: xml output changed - relative paths now appearing?
> It's fixed on trunk: > > http://subversion.tigris.org/issues/show_bug.cgi?id=4398 > > Sweet! Thanks a lot! -- Alexander Haley, Computer Scientist, 781-774-5156 Medical Information Technology, Inc. Mailstop: F4E16W, MEDITECH Circle, Westwood, MA 02090
RE: RESOLVED: SVN copy that worked in 1.8.0 now fails with (424 FailedDependency)
> -Original Message- > From: Philip Martin [mailto:philip.mar...@wandisco.com] > Sent: Wednesday, August 07, 2013 12:19 PM > To: Brenden Walker > Cc: users@subversion.apache.org > Subject: Re: RESOLVED: SVN copy that worked in 1.8.0 now fails with (424 > FailedDependency) > > Brenden Walker writes: > > >> > svn: E175002: Adding directory failed: COPY on > >> > /svn/Development/!svn/rvr/7020/Trunk/Projects/SiteWatch (424 Failed > >> > Dependency) > > > > Turned out that another developer had locks on several files. > > Confirmed that was the problem. A more specific error message would > > have been handy here. > > Can you describe how to reproduce the problem? What sort of locks prevent > a COPY? Orphaned locks perhaps? They were working copy locks from another developer. I asked him to try the build himself to see if it allows the user who holds the lock to svn copy, haven't heard back from that. Breaking the locks allowed me to do an SVN copy. I haven't tried reproducing, but I certainly can if that would be helpful.
Subversion Exception!
--- Subversion Exception! --- Subversion encountered a serious problem. Please take the time to report this on the Subversion mailing list with as much information as possible about what you were trying to do. But please first search the mailing list archives for the error message to avoid reporting the same problem repeatedly. You can find the mailing list archives at http://subversion.apache.org/mailing-lists.html Subversion reported the following (you can copy the content of this dialog to the clipboard using Ctrl-C): In file 'D:\Development\SVN\Releases\TortoiseSVN-1.8.1\ext\subversion\subversion\libsvn_client\commit_util.c' line 211: assertion failed (repos_root_url && repos_relpath) --- OK --- Best Regards Alexandre VION Software Engineer, Research & Development CP Technocenter Phone dir.: +33 (0)2 40 80 89 10 - Fax: +33 (0)2 40 80 20 24 E-mail: alexandre.v...@cp.com Think about environment. Save paper Visit us at: www.cp.com www.desouttertools.com www.fujitools.com www.rodcraft.com
Re: Subversion Exception!
On Wed, Aug 7, 2013 at 1:52 PM, wrote: > --- > Subversion Exception! > --- > Subversion encountered a serious problem. > Please take the time to report this on the Subversion mailing list > with as much information as possible about what > you were trying to do. > But please first search the mailing list archives for the error message > to avoid reporting the same problem repeatedly. > You can find the mailing list archives at > http://subversion.apache.org/mailing-lists.html > > Subversion reported the following > (you can copy the content of this dialog > to the clipboard using Ctrl-C): > > In file > > 'D:\Development\SVN\Releases\TortoiseSVN-1.8.1\ext\subversion\subversion\libsvn_client\commit_util.c' > line 211: assertion failed (repos_root_url && repos_relpath) Thank you for reading the message and doing *most* of what it asked you to do. But you need to describe *what* you were doing to cause this error to occur.
RE: RESOLVED: SVN copy that worked in 1.8.0 now fails with (424 FailedDependency)
> > Brenden Walker writes: > > > > >> > svn: E175002: Adding directory failed: COPY on > > >> > /svn/Development/!svn/rvr/7020/Trunk/Projects/SiteWatch (424 > > >> > Failed > > >> > Dependency) > > > > > > Turned out that another developer had locks on several files. > > > Confirmed that was the problem. A more specific error message would > > > have been handy here. > > > > Can you describe how to reproduce the problem? What sort of locks > > prevent a COPY? Orphaned locks perhaps? > > They were working copy locks from another developer. I asked him to try the > build himself to see if it allows the user who holds the lock to svn copy, > haven't > heard back from that. > > Breaking the locks allowed me to do an SVN copy. > > I haven't tried reproducing, but I certainly can if that would be helpful. Are you sharing working copies with multiple people? BOb
RE: RESOLVED: SVN copy that worked in 1.8.0 now fails with (424 FailedDependency)
> -Original Message- > From: Bob Archer [mailto:bob.arc...@amsi.com] > Sent: Wednesday, August 07, 2013 2:30 PM > To: Brenden Walker; Philip Martin > Cc: users@subversion.apache.org > Subject: RE: RESOLVED: SVN copy that worked in 1.8.0 now fails with (424 > FailedDependency) > > > > Brenden Walker writes: > > > > > > >> > svn: E175002: Adding directory failed: COPY on > > > >> > /svn/Development/!svn/rvr/7020/Trunk/Projects/SiteWatch (424 > > > >> > Failed > > > >> > Dependency) > > > > > > > > Turned out that another developer had locks on several files. > > > > Confirmed that was the problem. A more specific error message > > > > would have been handy here. > > > > > > Can you describe how to reproduce the problem? What sort of locks > > > prevent a COPY? Orphaned locks perhaps? > > > > They were working copy locks from another developer. I asked him to > > try the build himself to see if it allows the user who holds the lock > > to svn copy, haven't heard back from that. > > > > Breaking the locks allowed me to do an SVN copy. > > > > I haven't tried reproducing, but I certainly can if that would be helpful. > > Are you sharing working copies with multiple people? If by that you mean checking out somewhere and having multiple people using the same working copy, no. Each developer has their own working copy. The reason the files were locked is that they're unmergeable binaries, AND most people here are still used to StarTeam. I offered up some other options to keep other developers from accidentally changing these files.
