Re: Re: enhancement suggestion
[ Hi Christian, please keep the mailinglist in cc, i.e. use Reply All. Also, we prefer plain-text emails on this list, of possible. More below ...] On Wed, Apr 11, 2018 at 9:53 AM, Christian Klie wrote: >> What SVN version is the server? >> What SVN version is the client? > Both are version 1.9.7 (r1800392). > >> What version of back-end filesystem on the server (BDB or FSFS, which >> version)? > Path: . > UUID: 6baea231-e241-2848-b57a-28e303214589 > Repository Format: 5 > Compatible With Version: 1.9.0 > Repository Capability: mergeinfo > Filesystem Type: fsfs > Filesystem Format: 7 > FSFS Sharded: yes > FSFS Shard Size: 1000 > FSFS Shards Packed: 0/0 > FSFS Logical Addressing: yes > Configuration File: db\fsfs.conf > > >> Which version of Windows? > Windows 10 >> Anything special about that disk? > Format is exFAT Okay, that probably explains your problem. As Branko also said on this thread (but you might have missed it, he replied only to the list, so if you aren't subscribed ...): On Tue, Feb 20, 2018 at 4:29 PM, Branko Čibej wrote: > On 20.02.2018 15:59, Johan Corveleyn wrote: ... >> So the directory 5-6.txn below db/transactions showed: >> - Number of files: 244295 (0 folders) >> - Size: 88.6 MB >> - Size on disk: 29.8 GB >> (Wow, that's huge! For only 88.6 MB of data in 244295 files, that's a >> factor of more than 300 compared to the actual data size) > > 344 exactly. The filesystem cluster is 128 KiB and the average file size > is 380 bytes. The cluster (allocation unit) size is quite large, which > suggests it may not be NTFS, or it is a really humongously huge volume. See: > > https://support.microsoft.com/en-gb/help/140365/default-cluster-size-for-ntfs-fat-and-exfat If you go to the page linked above, you'll see at the bottom that the default cluster size for exFAT is 128 KB if your volume is 32 GB or larger. So this extremely large "size on disk" for so little actual data is expected, and is caused by the configuration of your filesystem. As Branko said, the easiest fix is to fix your filesystem. Either switch to NTFS or some other filesystem, or if you really *must* use exFAT, try to format the drive with a smaller cluster size (I suppose 128 KB is the default, but you can still use a smaller setting if you deviate from the default -- that's just a guess, I don't know exFAT). -- Johan
Re: win64 build
On Tue, Apr 3, 2018 at 6:26 PM, hasan kol wrote: > Hello, > > In FAQ, in the answer of the question "What operating systems does > Subversion run on?" Win64 is not present, unlike Unix, Win32, BeOS, OS/2 and > MacOS X. I think Win32 here just refers to the "Windows API" in general, not limited to 32-bit. As explained here, "Win32" is now just an alternative for "Windows API": https://www.computerhope.com/jargon/w/win32.htm > By any configuration in the build, is it possible to generate static libs > for Windows 64-bit (Win64)? Yes, certainly. See the list of binary packages listed here (most provide a 32-bit and a 64-bit version): https://subversion.apache.org/packages.html#windows -- Johan
Re: Inconsistent merge on subdirectory behavior?
On Wed, Apr 11, 2018 at 4:56 PM, Chris wrote:
> I wanted to reverse-merge some accidental changes on a subdirectory on my
> branch and svn really confuses me in this. Is the below behavior from
> subversion intended or have I stubled on a bug?
>
> I wanted to reverse-merge revision 1000 on all the files in the directory
> "sub/dir", below illustrated with only one file.
>
> wcroot> svn diff --summarize -c 1000 sub/dir
> M sub/dir/foobar.txt
> wcroot> svn merge -c -1000 sub/dir
> --- Recording mergeinfo for reverse merge of r1000 into '.':
> U .
> So the file sub/dir/foobar.txt is not reverse-merged (and the merge info is
> elided even though the output does not say so)
>
> I tried a few different versions of this with e.g. -r 1000:999 with identical
> results.
>
> Then I did the following, which I thought would be more of the same:
>
> wcroot> cd foo/bar
> wcroot/foo/bar> svn merge -c -1000 .
> --- Reverse-merging r1000 into '.':
> Usub/dir/foobar.txt
> --- Recording mergeinfo for reverse merge of r1000 into '.':
> G .
> --- Eliding mergeinfo from '.':
> U .
>
> So now it does what I wanted to.
>
> Is it intended that merge should do different things if I use "." or
> "sub/dir" as my WCTARGET? I find it confusing and it was mostly luck that I
> stumbled on the right solution. "svn help merge" does not seem to indicate
> that these two use cases should be any different, but I may misread it.
> Btw, this was done with "svn, version 1.9.5 (r1770682)"
>
> TIA,
> Chris
Hi Chris,
That does seem strange. However it's quite hard to diagnose this from
your description alone, because there are a lot of things that can
play a role in the merge algorithm.
Would you be able to come up with a reproduction script, or even just
a transcript of you reproducing the issue, starting from a clean
repository ('svnadmin create'; ...)?
For a reproduction script you could use the repro-template.sh or
repro-template.bat linked from here:
https://subversion.apache.org/docs/community-guide/issues.html#reporting-bugs
Thanks,
--
Johan
[ANNOUNCE] Apache Subversion 1.10.0 released
I'm happy to announce the release of Apache Subversion 1.10.0. Please choose the mirror closest to you by visiting: https://subversion.apache.org/download.cgi#recommended-release This is a stable feature release of the Apache Subversion open source version control system. The SHA1 checksums are: 345bc84edc5fe72f70997d247230fd8d3a18d83b subversion-1.10.0.tar.bz2 383e69c077a985bf5a091494d45655714180d5cb subversion-1.10.0.tar.gz 9facdb5a5652b5d90fe9afaebf97ed6b94cf657c subversion-1.10.0.zip SHA-512 checksums are available at: https://www.apache.org/dist/subversion/subversion-1.10.0.tar.bz2.sha512 https://www.apache.org/dist/subversion/subversion-1.10.0.tar.gz.sha512 https://www.apache.org/dist/subversion/subversion-1.10.0.zip.sha512 PGP Signatures are available at: https://www.apache.org/dist/subversion/subversion-1.10.0.tar.bz2.asc https://www.apache.org/dist/subversion/subversion-1.10.0.tar.gz.asc https://www.apache.org/dist/subversion/subversion-1.10.0.zip.asc For this release, the following people have provided PGP signatures: Julian Foad [4096R/1FB064B84EECC493] with fingerprint: 6011 63CF 9D49 9FD7 18CF 582D 1FB0 64B8 4EEC C493 Philip Martin [2048R/76D788E1ED1A599C] with fingerprint: A844 790F B574 3606 EE95 9207 76D7 88E1 ED1A 599C Stefan Sperling [2048R/4F7DBAA99A59B973] with fingerprint: 8BC4 DAE0 C5A4 D65F 4044 0107 4F7D BAA9 9A59 B973 Stefan Hett (CODE SIGNING KEY) [4096R/376A3CFD110B1C95] with fingerprint: 7B8C A7F6 451A D89C 8ADC 077B 376A 3CFD 110B 1C95 Branko Čibej [4096R/1BCA6586A347943F] with fingerprint: BA3C 15B1 337C F0FB 222B D41A 1BCA 6586 A347 943F Johan Corveleyn [4096R/B59CE6D6010C8AAD] with fingerprint: 8AA2 C10E EAAD 44F9 6972 7AEA B59C E6D6 010C 8AAD Release notes for the 1.10.x release series may be found at: https://subversion.apache.org/docs/release-notes/1.10.html You can find the list of changes between 1.10.0 and earlier versions at: https://svn.apache.org/repos/asf/subversion/tags/1.10.0/CHANGES Questions, comments, and bug reports to users@subversion.apache.org. Thanks, - The Subversion Team -- To unsubscribe, please see: https://subversion.apache.org/mailing-lists.html#unsubscribing
How to disable lz4 support when library is installed in system?
What should I pass to "configure" to PREVENT detection & usage of lz4 library installed in system? `--without-lz4' doesn't work. -- // Black Lion AKA Lev Serebryakov
Re: How to disable lz4 support when library is installed in system?
--with-lz4=internal may be what you want. From what I can gather lz4 is the future so I would be surprised if you can prevent it’s usage. Jonathan > On 13 Apr 2018, at 16:13, Lev Serebryakov wrote: > > > What should I pass to "configure" to PREVENT detection & usage of lz4 > library installed in system? `--without-lz4' doesn't work. > > -- > // Black Lion AKA Lev Serebryakov
Strange libtool errors when try to build pyhton and ruby bindings (1.10.0)
I'm preparing FreeBSD of subversion-1.10.0 and have very strange errors when try to build bindings. subversion itself builds without problems. python one: /bin/sh "/usr/home/lev/FreeBSD/ports/devel/py-subversion/work-py34/subversion-1.10.0/libtool" --tag=CC --silent --mode=compile-DSWIGPYTHON -I/usr/home/lev/FreeBSD/ports/devel/py-subversion/work-py34/subversion-1.10.0/subversion/bindings/swig/python/libsvn_swig_py -I./subversion/include -I./subversion -I/usr/local/include/apr-1 -I/usr/local/include/apr-1 -I/usr/local/include -I/usr/local/include/serf-1 -I/usr/local/include -I/usr/local/include -I/usr/local/include -o subversion/bindings/swig/python/libsvn_swig_py/swigutil_py.lo -c subversion/bindings/swig/python/libsvn_swig_py/swigutil_py.c Usage: /usr/home/lev/FreeBSD/ports/devel/py-subversion/work-py34/subversion-1.10.0/libtool [OPTION]... [MODE-ARG]... Try 'libtool --help' for more information. libtool: error: unrecognised option: '-DSWIGPYTHON' *** Error code 1 ruby one: /bin/sh "/usr/home/lev/FreeBSD/ports/devel/ruby-subversion/work/subversion-1.10.0/libtool" --tag=CC --silent --mode=compile -I/usr/home/lev/FreeBSD/ports/devel/ruby-subversion/work/subversion-1.10.0/subversion/bindings/swig/ruby/libsvn_swig_ruby -I./subversion/include -I./subversion -I/usr/local/include/apr-1 -I/usr/local/include/apr-1 -I/usr/local/include -I/usr/local/include/serf-1 -I/usr/local/include -I/usr/local/include -I/usr/local/include -o subversion/bindings/swig/ruby/libsvn_swig_ruby/swigutil_rb.lo -c subversion/bindings/swig/ruby/libsvn_swig_ruby/swigutil_rb.c Usage: /usr/home/lev/FreeBSD/ports/devel/ruby-subversion/work/subversion-1.10.0/libtool [OPTION]... [MODE-ARG]... Try 'libtool --help' for more information. libtool: error: unrecognised option: '-I/usr/home/lev/FreeBSD/ports/devel/ruby-subversion/work/subversion-1.10.0/subversion/bindings/swig/ruby/libsvn_swig_ruby' *** Error code 1 -- // Black Lion AKA Lev Serebryakov
Re: Strange libtool errors when try to build pyhton and ruby bindings (1.10.0)
On 13.04.2018 19:20, Lev Serebryakov wrote: > I'm preparing FreeBSD of subversion-1.10.0 and have very strange errors > when try to build bindings. > > subversion itself builds without problems. > > python one: > > ruby one: > Commands (cc) are missed in both cases. perl and Java bindings don't have this problem. -- // Black Lion AKA Lev Serebryakov
SVN E170001: Authentication error with specific user/realm/pw combinations while many other work!
Summary: SVN E170001: Authentication error with specific user/realm/pw combinations while many other work! Observations/Workarounds While there is a work around, by simply changing the password, we have an unusual reoccurring issue with some user/realm/password combinations. It's a problem setting the same password to many repos. The issue shows up under both CRAM-MD5 and DIGEST-MD5, but not for the same user/realm/password. >From and SVN perspective: How do I get svn/svnserve to log the hashed response so I can compare it outside of SASL and MYSQL. I suspect our method to generate the hashed CRAM-MD5 and DIGEST-MD5 that we store in mysql has a bug, what is a good place to locate source for this program. Use Case is a simple svn task: $svn list svn://SVN.HOST.DOMAIN:12000 Server Config svnserver configured via sasl mechanism CRAM-MD5 and/or Digest-MD5 - Hashed passwd stored in mysqlDB separate realm for each repo Assumptions: Since it works most of the time, configurations are correct. Issue: Some password combinations return svn: E170001: Authentication error from server: SASL(-13): authentication failure: incorrect digest response User/process quick check: when we suspect an issue we compare the generated hash with DB stored hash to rule out, process, user and DB issue. gen_hash - user realm passwd using sasl_passwd binary query_hash - query user realm from MYSQL DB inspect HEX gen_hash ~ HEX query_hash if hash matches, we expect $svn list user passwd svn://SVN.HOST.DOMAIN:12000 to be successful. Summary Sample tests updating mysqlDB and running svn list using a different password Works- Capmpwds2018 Works- apmpwds2018 Fails- capmpwds2018 Works- cApmpwds2018 Test SCRIPT ksh ./add_user.sh:prod m80154 Capmpwds2018 capmbat2 update The DB agrees with user/pw/realm DB cmusaslsecretCRAM-MD5 6FE5A5552D2F13F7BDBF6FB2AE9B1A125313C2BA79479D153877B95CFA9DFC29 Commandline CRAM USER:HEX/UN 6FE5A5552D2F13F7BDBF6FB2AE9B1A125313C2BA79479D153877B95CFA9DFC29 Success m80154 - /opt/app/scm/svn/binaries/svn_1.9.7/bin/svn --no-auth-cache --username m80154 --password Capmpwds2018 list svn://SVN.HOST.DOMAIN:12000 $ksh ./add_user.sh:prod m80154 apmpwds2018 capmbat2 update The DB agrees with user/pw/realm DB cmusaslsecretCRAM-MD5 6A2912411C7616DECF97A2B7582ADEF4855C3B4E4373046832D242AEC4AC08E2 Commandline CRAM USER:HEX/UN 6A2912411C7616DECF97A2B7582ADEF4855C3B4E4373046832D242AEC4AC08E2 Success m80154 - /opt/app/scm/svn/binaries/svn_1.9.7/bin/svn --no-auth-cache --username m80154 --password apmpwds2018 list svn://SVN.HOST.DOMAIN:12000 ksh ./add_user.sh:prod m80154 capmpwds2018 capmbat2 update The DB agrees with user/pw/realm DB cmusaslsecretCRAM-MD5 59B803D644BC84CF91230A8FFEA371A3421AE83003009232483A3FEF5B90BE6A Commandline CRAM USER:HEX/UN 59B803D644BC84CF91230A8FFEA371A3421AE83003009232483A3FEF5B90BE6A Failed m80154 /opt/app/scm/svn/binaries/svn_1.9.7/bin/svn --no-auth-cache --username m80154 --password capmpwds2018 list svn://SVN.HOST.DOMAIN:12000 svn: E170013: Unable to connect to a repository at URL 'svn://SVN.HOST.DOMAIN:12000' svn: E170001: Authentication error from server: SASL(-13): authentication failure: incorrect digest response $ksh ./add_user.sh:prod m80154 cApmpwds2018 capmbat2 update The DB agrees with user/pw/realm DB cmusaslsecretCRAM-MD5 9328603F62A27B23C3A01149D8CA97BB5885F9163C9498918FDD2223439EED26 Commandline CRAM USER:HEX/UN 9328603F62A27B23C3A01149D8CA97BB5885F9163C9498918FDD2223439EED26 Success m80154 - /opt/app/scm/svn/binaries/svn_1.9.7/bin/svn --no-auth-cache --username m80154 --password cApmpwds2018 list svn://SVN.HOST.DOMAIN:12000 -
