Re: Build problems on Fedora 19 x86_64

[Philip Martin]

George R Goffe  writes:

> /usr/bin/ld: skipping incompatible /usr/lib/libc.so when searching for -lc
> /usr/bin/ld: skipping incompatible /usr/lib/libc.a when searching for -lc

The "skipping" lines merely indicate that the linker is finding both 32
and 64 bit libraries and ignoring some of them.

> /tools/subversion/subversion/subversion/svnserve/subversion/svnserve/serve.c:171:
>  undefined reference to `logger__write'

> /tools/subversion/subversion/subversion/svnserve/subversion/svnserve/svnserve.c:480:
>  undefined reference to `svn_root_pools__release_pool'

These errors are the problem and they all refer to symbols that are new
in trunk.  One known cause is when libtool, patched by the distribution,
finds the installed libraries rather than the just build libraries.  If
you have old libraries, say 1.8, already installed in the intended
installation directory then using the patched libtool will fail.  Either
remove the old libraries or use a libtool without the bug.

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

RE: Setting sticky depth without grabbing content immediately

[Bert Huijben]

> -Original Message-
> From: OBones [mailto:obo...@free.fr]
> Sent: dinsdag 5 november 2013 14:06
> To: Subversion Users
> Subject: Re: Setting sticky depth without grabbing content immediately
> 
> Johan Corveleyn wrote:
> > I think this would be a useful feature. Whether or not someone will
> > have time to work on it, or someone steps up to write a patch for it,
> > is another matter. But I'd suggest that you enter this into the issue
> > tracker in any case. Can you please file an issue for this?
> Done: http://subversion.tigris.org/issues/show_bug.cgi?id=4445

Currently the Subversion working only stores one depth value and this depth
must match what is known about the children. 

If you would update this depth to infinity it would imply that all the
children are known in the working copy and a further update would not bring
them in. Fixing this requires keeping a second depth value just to allow
this UI in one of many Subversion clients, with all kind of backwards
compatibility concerns.

What you could do is update/checkout the directory as r0 / the revision in
which it was created. In that revision it most likely doesn't have any
children. The further update would then go to the HEAD revision in which the
children are there.

If you are going to re-use that working copy as template (as I guess from
your question) I would recommend running 'svn cleanup' on it before storing,
to remove unneeded data in the .svn directory.

Bert
> 
> Regards

Re: Setting sticky depth without grabbing content immediately

[Johan Corveleyn]

On Wed, Nov 6, 2013 at 12:33 PM, Bert Huijben  wrote:
>
>
>> -Original Message-
>> From: OBones [mailto:obo...@free.fr]
>> Sent: dinsdag 5 november 2013 14:06
>> To: Subversion Users
>> Subject: Re: Setting sticky depth without grabbing content immediately
>>
>> Johan Corveleyn wrote:
>> > I think this would be a useful feature. Whether or not someone will
>> > have time to work on it, or someone steps up to write a patch for it,
>> > is another matter. But I'd suggest that you enter this into the issue
>> > tracker in any case. Can you please file an issue for this?
>> Done: http://subversion.tigris.org/issues/show_bug.cgi?id=4445
>
> Currently the Subversion working only stores one depth value and this depth
> must match what is known about the children.
>
> If you would update this depth to infinity it would imply that all the
> children are known in the working copy and a further update would not bring
> them in. Fixing this requires keeping a second depth value just to allow
> this UI in one of many Subversion clients, with all kind of backwards
> compatibility concerns.

Perhaps a dumb question...

I don't know whether subversion first sets the depth value in the
metadata, and then processes the update, or vice versa. But if it's
the former, what happens when the update is interrupted after storing
the new depth value but before the children have been "received"? I
suppose this will mean the directory is marked as incomplete or
something like that, so that a subsequent update completes the update
and brings in everything?

Couldn't something similar be used for this use case? I.e. you create
/ prepare an "incomplete working copy" (or where some parts are
incomplete).

-- 
Johan

Re: Build problems on Fedora 19 x86_64

[Nico Kadel-Garcia]

On Wed, Nov 6, 2013 at 5:33 AM, Philip Martin
 wrote:
> George R Goffe  writes:
>
>> /usr/bin/ld: skipping incompatible /usr/lib/libc.so when searching for -lc
>> /usr/bin/ld: skipping incompatible /usr/lib/libc.a when searching for -lc
>
> The "skipping" lines merely indicate that the linker is finding both 32
> and 64 bit libraries and ignoring some of them.
>
>> /tools/subversion/subversion/subversion/svnserve/subversion/svnserve/serve.c:171:
>>  undefined reference to `logger__write'
>
>> /tools/subversion/subversion/subversion/svnserve/subversion/svnserve/svnserve.c:480:
>>  undefined reference to `svn_root_pools__release_pool'
>
> These errors are the problem and they all refer to symbols that are new
> in trunk.  One known cause is when libtool, patched by the distribution,
> finds the installed libraries rather than the just build libraries.  If
> you have old libraries, say 1.8, already installed in the intended
> installation directory then using the patched libtool will fail.  Either
> remove the old libraries or use a libtool without the bug.
>
> --
> Philip Martin | Subversion Committer
> WANdisco // *Non-Stop Data*

This is partly why building from an SRPM, using "mock", can  be so
helpful. "mock" creates a chroot cage with only the designated build
requirements in it, and helps avoid this problem and others when an
incompatible library is installed locally on your system, but is not
part of available RPM's.

Re: Build problems on Fedora 19 x86_64

[Philip Martin]

Philip Martin  writes:

> George R Goffe  writes:
>
>> /tools/subversion/subversion/subversion/svnserve/subversion/svnserve/serve.c:171:
>>  undefined reference to `logger__write'
>
>> /tools/subversion/subversion/subversion/svnserve/subversion/svnserve/svnserve.c:480:
>>  undefined reference to `svn_root_pools__release_pool'
>
> These errors are the problem and they all refer to symbols that are new
> in trunk.  One known cause is when libtool,

Since these new trunk symbols are defined in new source files another
option is that you failed to regenerate the Makefile dependencies by
rerunning gen-make.py in the source directory.

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

svn: E170000: Unrecognized URL scheme for 'http://llvm.org/svn/llvm-project/llvm/trunk'

[Alec Taylor]

Hi svn users; just trying to troubleshoot this error.

I am running Sun OS 5.10 (Solaris 10) on a SPARC machine, with the
latest coreutils [8.21], make [4.0], awk [4.1.0] and gcc [4.8.2] used
to build the latest Apache Subversion [1.8.4 (r1534716)].

Why is this happening?

$ svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm-trunk
svn: E17: Unrecognized URL scheme for
'http://llvm.org/svn/llvm-project/llvm/trunk'

Re: svn: E170000: Unrecognized URL scheme for 'http://llvm.org/svn/llvm-project/llvm/trunk'

[Ryan Schmidt]

On Nov 5, 2013, at 23:54, Alec Taylor wrote:

> I am running Sun OS 5.10 (Solaris 10) on a SPARC machine, with the
> latest coreutils [8.21], make [4.0], awk [4.1.0] and gcc [4.8.2] used
> to build the latest Apache Subversion [1.8.4 (r1534716)].
> 
> Why is this happening?
> 
> $ svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm-trunk
> svn: E17: Unrecognized URL scheme for
> 'http://llvm.org/svn/llvm-project/llvm/trunk'

Sounds like http is an unrecognized url scheme for your svn client.

This could occur if you didn’t compile svn with an http client library, like 
serf.

“svn --version” shows you all the schemes your svn supports.

symlinks on Windows

[Randy Defauw]

Hi,

Any thoughts regarding supporting symlinks on Windows?  Windows has
supported symlinks since Vista:

http://msdn.microsoft.com/en-us/library/windows/desktop/aa365680(v=vs.85).aspx

Supporting cross-platform symlinks where possible will ease some
compatibility pain for cross-platform development.


Randy DeFauw I *Director, ALM Product Marketing*

WANdisco // *Non-Stop Data*

t. 720-255-2774
e. randy.def...@wandisco.com
twitter @rdefauw 

-- 
Listed on the London Stock Exchange: 
WAND

THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY, AND MAY BE 
PRIVILEGED.  If this message was misdirected, WANdisco, Inc. and its 
subsidiaries, ("WANdisco") does not waive any confidentiality or privilege. 
 If you are not the intended recipient, please notify us immediately and 
destroy the message without disclosing its contents to anyone.  Any 
distribution, use or copying of this e-mail or the information it contains 
by other than an intended recipient is unauthorized.  The views and 
opinions expressed in this e-mail message are the author's own and may not 
reflect the views and opinions of WANdisco, unless the author is authorized 
by WANdisco to express such views or opinions on its behalf.  All email 
sent to or from this address is subject to electronic storage and review by 
WANdisco.  Although WANdisco operates anti-virus programs, it does not 
accept responsibility for any damage whatsoever caused by viruses being 
passed.

svnadmin hotcopy losing revprops

[dpm]

I'm using svn 1.8.4 on RHEL 6.3 (we're in the process of trying to upgrade 
from svn 1.6 to 1.8).
However, the svnadmin hotcopy command doesn't appear to be working 
correctly with the
repositories I've copied over from our 1.6 server - most of the db/revprop 
directories are missing.
See output below.
It works OK if I upgrade the repository first.
Am I missing something obvious?

Thanks

+ cat orig.svn/format
5
+ cat orig.svn/db/min-unpacked-rev
7000
+ ls orig.svn/db/revprops
0  1  2  3  4  5  6  7
+ svnadmin verify -q orig.svn
+ svnadmin hotcopy orig.svn copy.svn
+ ls copy.svn/db/revprops
0  7
+ diff -r orig.svn copy.svn
Binary files orig.svn/db/rep-cache.db and copy.svn/db/rep-cache.db differ
Only in orig.svn/db: rev-prop-atomics.shm
Only in orig.svn/db/revprops: 1
Only in orig.svn/db/revprops: 2
Only in orig.svn/db/revprops: 3
Only in orig.svn/db/revprops: 4
Only in orig.svn/db/revprops: 5
Only in orig.svn/db/revprops: 6
Only in copy.svn/db: txn-current-lock
Only in copy.svn/db: write-lock
+ svnadmin verify -q copy.svn
svnadmin: E02: Can't open file 'copy.svn/db/revprops/1/1000': No such 
file or directory
+ svnadmin upgrade orig.svn
Repository lock acquired.
Please wait; upgrading the repository may take some time...

Upgrade completed.
+ svnadmin hotcopy orig.svn copy2.svn
+ diff -r orig.svn copy2.svn
Binary files orig.svn/db/rep-cache.db and copy2.svn/db/rep-cache.db differ
Only in orig.svn/db: rev-prop-atomics.shm
Only in copy2.svn/db: txn-current-lock
+ svnadmin verify -q copy2.svn