Re: Mergeinfo overwritten from successive merges
Over on users@, we got a report about mergeinfo being overwritten when two different merges to the same branch were made from different working copies. I've been able to reproduce this with the attached script; but only via http://, local:// and svn:// refuse to commit the second merge, as expected. Another data point: this can only be reproduced when 'trunk' and 'branch' are not related; if I create 'branch' as a copy of 'trunk', this does not happen. The Apache config I used was a simple LoadModule dav_svn_module /usr/local/opt/subversion/libexec/mod_dav_svn.so DAV svn SVNPath /tmp/test/repo Order allow,deny Allow from all Here's the output of my script: brane@zulu:/tmp/test$ ~/repro2.sh + svnadmin create repo + svn checkout http://localhost/repro/repo structure Checked out revision 0. + svn mkdir structure/trunk A structure/trunk + svn mkdir structure/branch A structure/branch + svn commit -mm structure Adding structure/branch Adding structure/trunk Committed revision 1. + echo aa + svn add structure/trunk/a A structure/trunk/a + svn commit -mm structure Adding structure/trunk/a Transmitting file data . Committed revision 2. + echo bb + svn add structure/trunk/b A structure/trunk/b + svn commit -mm structure Adding structure/trunk/b Transmitting file data . Committed revision 3. + svn checkout http://localhost/repro/repo/branch user1 Checked out revision 3. + svn checkout http://localhost/repro/repo/branch user2 Checked out revision 3. + svn merge -c2 http://localhost/repro/repo/trunk user1 --- Merging r2 into 'user1': Auser1/a --- Recording mergeinfo for merge of r2 into 'user1': U user1 + svn commit -mm user1 Sendinguser1 Adding user1/a Committed revision 4. + svn proplist -v http://localhost/repro/repo/branch Properties on 'http://localhost/repro/repo/branch': svn:mergeinfo /trunk:2 + svn merge -c3 http://localhost/repro/repo/trunk user2 --- Merging r3 into 'user2': Auser2/b --- Recording mergeinfo for merge of r3 into 'user2': U user2 + svn commit -mm user2 Sendinguser2 Adding user2/b Committed revision 5. + svn proplist -v http://localhost/repro/repo/branch Properties on 'http://localhost/repro/repo/branch': svn:mergeinfo /trunk:3 -- Brane On 14.03.2014 06:21, Branko Čibej wrote: > On 14.03.2014 02:18, Jeb Wilson wrote: >> >> Hello, >> >> >> >> I’ve reproduced this mergeinfo overwriting issue using the following >> steps. We are seeing this with svn client v1.8.8, and using a remote >> VisualSVN server v2.7.0 (which uses svn v1.8.8). NOTE: This cannot be >> replicated by using a locally created repo…we’ve only been able to >> replicate with VisualSVN remotely. >> >> >> >> TO REPRODUCE: >> >> We started out by creating an empty repo called TestRepo on the >> server. Then: >> >> >> >> E:\Colspace\sandbox2>mkdir fullrepo >> >> >> >> E:\Colspace\sandbox2>svn checkout >> https://svn.colspace.com/svn/TestRepo fullrepo >> >> >> >> Checked out revision 0. >> >> >> >> E:\Colspace\sandbox2>cd fullrepo >> >> >> >> E:\Colspace\sandbox2\fullrepo>svn mkdir trunk >> >> A trunk >> >> >> >> E:\Colspace\sandbox2\fullrepo>svn mkdir branch >> >> A branch >> > > I can reproduce this, using http:// and the exact structure you're > using -- i.e., when 'trunk' and 'branch' are not related, as in your > case. When they are related (that is, 'branch' is a copy of 'trunk'), > the commit after the second merge fails, as expected. > > I'm not entirely sure if this is expected behaviour or not, but I > suspect it isn't. Can you please report an issue? > > -- Brane > > > -- > Branko Čibej | Director of Subversion > WANdisco // Non-Stop Data > e. br...@wandisco.com -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com repro2.sh Description: Bourne shell script
[PATCH] Tests harness: multiple calls to create_python_hook_script
The svntest/main.py code that installs a post-commit hook for --fsfs-packing=N
documents the following shortcoming:
# Note that some tests (currently only commit_tests) create their own
# post-commit hooks, which would override this one. :-(
In general, if a test calls create_python_hook_script() twice with the same
HOOK_PATH argument, all calls but the last are *silently ignored*. That's bad.
I'm attaching a patch for this. I ran tests through merge_reintegrate_tests.py
and it doesn't introduce any failures. I probably won't have time to finish
it, so I'd appreciate it if someone can pick it up, finish it, and commit.
Thanks.
Daniel
[[[
Tests harness: fix a bug whereby a previously-installed hook would be silently
overwritten by a more-recently-installed one.
TODO: before commit, fix commit_tests 15 and 38 under --fsfs-packing
* subversion/tests/cmdline/svntest/main.py
(errno): Import
(create_repos): Undocument the bug this commit fixes.
(create_python_hook_script): Abort if the hook script already exists.
There is no provision for callers to disable this behaviour.
* subversion/tests/cmdline/commit_tests.py
(hook_test, post_commit_hook_test): (...)
]]]
[[[
--- subversion/tests/cmdline/svntest/main.py
+++ subversion/tests/cmdline/svntest/main.py
@@ -37,6 +37,7 @@ import urllib
import logging
import hashlib
from urlparse import urlparse
+import errno
try:
# Python >=3.0
@@ -973,8 +973,6 @@ def create_repos(path, minor_version = None):
file_write(format_file_path, new_contents, 'wb')
# post-commit
-# Note that some tests (currently only commit_tests) create their own
-# post-commit hooks, which would override this one. :-(
if options.fsfs_packing:
# some tests chdir.
abs_path = os.path.abspath(path)
@@ -1080,6 +1081,13 @@ def create_python_hook_script(hook_path,
hook_script_code,
"""Create a Python hook script at HOOK_PATH with the specified
HOOK_SCRIPT_CODE."""
+ # Hook scripts belong to a repository. Each repository is handled by at most
+ # one thread at any given time. Therefore, an advance check suffices, i.e.,
+ # open(O_EXCL) is not needed here.
+ if os.path.exists(hook_path):
+raise OSError(errno.EEXIST,
+ "Won't overwrite hook script at %r" % (hook_path,))
+
if windows:
if cmd_alternative is not None:
file_write("%s.bat" % hook_path,
--- subversion/tests/cmdline/commit_tests.py
+++ subversion/tests/cmdline/commit_tests.py
@@ -840,6 +840,7 @@ fp.close()"""
svntest.main.create_python_hook_script(pre_commit_hook,
hook_format % "pre_commit_hook")
+ # ### This test and post_commit_hook_test() probably to be changed before
commit.
post_commit_hook = svntest.main.get_post_commit_hook_path(repo_dir)
svntest.main.create_python_hook_script(post_commit_hook,
hook_format % "post_commit_hook")
]]]
Re: PACK_AFTER_EVERY_COMMIT and svnadmin_tests.py
Ben Reser wrote on Thu, Mar 13, 2014 at 16:51:58 -0700:
> Using this compile time definition causes two tests to fail in
> svnadmin_tests.py
>
> {{{
...
> }}}
>
> After some discussion on IRC I started trying to fix this by shifting the
> PACK_AFTER_EVERY_COMMIT to a fsfs.conf configuration (committed in r1577362).
> So that these tests could turn off packing after every commit to allow them to
> actually test svnadmin packing.
>
> Right now we have both PACK_AFTER_EVERY_COMMIT and a --fsfs-packing option to
> our tests. The first one inserts a pack operation as part of the transaction
> commit in the libsvn_fs library. The second one adds a post-commit hook that
> does the pack.
>
> According to Daniel, there was a bug found by PACK_AFTER_EVERY_COMMIT that the
> --fsfs-packing option didn't find. I honestly don't see how unless the test
> had its own post-commit hook, which there is a conflict. See:
> http://svn.apache.org/r875598
>
r875598 just adds PACK_AFTER_EVERY_COMMIT; the bug you refer to is the one
fixed by (aka r35523). The reason post-commit
hooks didn't find that bug was that the repository in question had only one
commit, and that commit was r1, which sbox.build() created via 'svnadmin load'
--- which bypasses hooks but did trigger the C post-commit packing in
svn_fs_commit_txn().
> My inclination here is to change --fsfs-packing to simply use the new
> fsfs.conf
> option I set.
Hmm. My gut feeling is that there might be future bugs which will be caught by
running 'svnadmin pack' from a hook but not by running it directly in C; but I
don't recall if there were such bugs in the past.
In other words, I think the hook-based packing is still useful, despite
the promotion of the C-based packing (from compile-time knob in
libsvn_fs to unadvertised runtime knob in fs_fs.c).
> Change the failing tests to no longer not run with packing and instead change
> the conf to disable packing (i.e. allow individual tests to override things
> like --fsfs-packing).
+1, since those two tests concern packing specifically.
> The alternative would be to fix the test suite to support multiple bits of
> code
> for a single hook script. But that seems far more complicated.
AFAICT, the only tests that write a post-commit hook are 'hook_test' and
'post_commit_hook_test' in commit_tests.py, so we might be able to tweak those
two callsites and avoid implementing a general "Multiple post-commit callbacks"
feature in the test harness.
(I haven't checked in detail at our options: perhaps we make those tests
explicitly disable fsfs_packing's hook script, or perhaps we skip them when
fsfs_packing is set, etc.)
> Any other opinions here?
PACK_AFTER_EVERY_COMMIT and svnadmin_tests.py
Using this compile time definition causes two tests to fail in svnadmin_tests.py
{{{
[[[
W: Unexpected output
W: EXPECTED STDOUT:
W: | Packing revisions in shard 1...done.
W: ACTUAL STDOUT:
W: DIFF STDOUT:
W: | --- EXPECTED STDOUT
W: | +++ ACTUAL STDOUT
W: | @@ -1 +0,0 @@
W: | -Packing revisions in shard 1...done.
W: CWD: /Users/breser/wandisco/builds/svn-trunk/subversion/tests/cmdline
W: EXCEPTION: SVNLineUnequal
Traceback (most recent call last):
File
"/Users/breser/wandisco/share/wcs/svn-trunk/subversion/tests/cmdline/svntest/main.py",
line 1598, in run
rc = self.pred.run(sandbox)
File
"/Users/breser/wandisco/share/wcs/svn-trunk/subversion/tests/cmdline/svntest/testcase.py",
line 254, in run
return self._delegate.run(sandbox)
File
"/Users/breser/wandisco/share/wcs/svn-trunk/subversion/tests/cmdline/svntest/testcase.py",
line 254, in run
return self._delegate.run(sandbox)
File
"/Users/breser/wandisco/share/wcs/svn-trunk/subversion/tests/cmdline/svntest/testcase.py",
line 176, in run
return self.func(sandbox)
File
"/Users/breser/wandisco/share/wcs/svn-trunk/subversion/tests/cmdline/svnadmin_tests.py",
line 1800, in hotcopy_incremental_packed
None, expected_output, [], "pack", os.path.join(cwd, sbox.repo_dir))
File
"/Users/breser/wandisco/share/wcs/svn-trunk/subversion/tests/cmdline/svntest/actions.py",
line 230, in run_and_verify_svnadmin
expected_exit, *varargs)
File
"/Users/breser/wandisco/share/wcs/svn-trunk/subversion/tests/cmdline/svntest/actions.py",
line 238, in run_and_verify_svnadmin2
expected_stdout, expected_stderr)
File
"/Users/breser/wandisco/share/wcs/svn-trunk/subversion/tests/cmdline/svntest/verify.py",
line 452, in verify_outputs
compare_and_display_lines(message, label, expected, actual, raisable)
File
"/Users/breser/wandisco/share/wcs/svn-trunk/subversion/tests/cmdline/svntest/verify.py",
line 425, in compare_and_display_lines
raise raisable
SVNLineUnequal
FAIL: svnadmin_tests.py 28: 'svnadmin hotcopy --incremental' with packing
]]]
[[[
W: Unexpected output
W: EXPECTED STDOUT:
W: | Packing revisions in shard 0...done.
W: | Packing revisions in shard 1...done.
W: | Packing revisions in shard 2...done.
W: ACTUAL STDOUT:
W: DIFF STDOUT:
W: | --- EXPECTED STDOUT
W: | +++ ACTUAL STDOUT
W: | @@ -1,3 +0,0 @@
W: | -Packing revisions in shard 0...done.
W: | -Packing revisions in shard 1...done.
W: | -Packing revisions in shard 2...done.
W: CWD: /Users/breser/wandisco/builds/svn-trunk/subversion/tests/cmdline
W: EXCEPTION: SVNLineUnequal
Traceback (most recent call last):
File
"/Users/breser/wandisco/share/wcs/svn-trunk/subversion/tests/cmdline/svntest/main.py",
line 1598, in run
rc = self.pred.run(sandbox)
File
"/Users/breser/wandisco/share/wcs/svn-trunk/subversion/tests/cmdline/svntest/testcase.py",
line 254, in run
return self._delegate.run(sandbox)
File
"/Users/breser/wandisco/share/wcs/svn-trunk/subversion/tests/cmdline/svntest/testcase.py",
line 176, in run
return self.func(sandbox)
File
"/Users/breser/wandisco/share/wcs/svn-trunk/subversion/tests/cmdline/svnadmin_tests.py",
line 2375, in verify_packed
"pack", sbox.repo_dir)
File
"/Users/breser/wandisco/share/wcs/svn-trunk/subversion/tests/cmdline/svntest/actions.py",
line 230, in run_and_verify_svnadmin
expected_exit, *varargs)
File
"/Users/breser/wandisco/share/wcs/svn-trunk/subversion/tests/cmdline/svntest/actions.py",
line 238, in run_and_verify_svnadmin2
expected_stdout, expected_stderr)
File
"/Users/breser/wandisco/share/wcs/svn-trunk/subversion/tests/cmdline/svntest/verify.py",
line 452, in verify_outputs
compare_and_display_lines(message, label, expected, actual, raisable)
File
"/Users/breser/wandisco/share/wcs/svn-trunk/subversion/tests/cmdline/svntest/verify.py",
line 425, in compare_and_display_lines
raise raisable
SVNLineUnequal
FAIL: svnadmin_tests.py 39: verify packed with small shards
]]]
}}}
After some discussion on IRC I started trying to fix this by shifting the
PACK_AFTER_EVERY_COMMIT to a fsfs.conf configuration (committed in r1577362).
So that these tests could turn off packing after every commit to allow them to
actually test svnadmin packing.
Right now we have both PACK_AFTER_EVERY_COMMIT and a --fsfs-packing option to
our tests. The first one inserts a pack operation as part of the transaction
commit in the libsvn_fs library. The second one adds a post-commit hook that
does the pack.
According to Daniel, there was a bug found by PACK_AFTER_EVERY_COMMIT that the
--fsfs-packing option didn't find. I honestly don't see how unless the test
had its own post-commit hook, which there is a conflict. See:
http://svn.apache.org/r875598
My inclination here is to change --fsfs-packing to simply use the new fsfs.conf
option I set. Change the failing tests to no longer not run with packing and
instead change the conf to disable packing (i.e. allow individual tests to
override things like --fsfs-packing).
The alternat
Re: Subversion checked-out files not indexed in Windows search
On 13 March 2014 21:52, Stefan Kueng wrote: > On 13.03.2014 14:14, Bert Huijben wrote: >> >> >> >>> -Original Message- >>> From: Ivan Zhakov [mailto:i...@visualsvn.com] >>> Sent: donderdag 13 maart 2014 13:56 >>> To: Branko Čibej >>> Cc: Subversion Development >>> Subject: Re: Subversion checked-out files not indexed in Windows search >>> >>> On 13 March 2014 16:46, Branko Čibej wrote: On 13.03.2014 13:37, Ivan Zhakov wrote: On 12 March 2014 18:17, Gareth McCaughan wrote: Ivan Zhakov wrote: It looks like serious issue. Could you please file issue in Subversion issue tracker: http://subversion.tigris.org/issues Done. Issue #4478. Gareth, thanks a lot! It seems we have second reason to create temporary files in target WC directory, instead of .svn/tmp. Another problem we had before is inherited ACL on Windows discussed year ago: http://mail-archives.apache.org/mod_mbox/subversion- >>> >>> dev/201309.mbox/%3C20130928110059.d1bb8d007dfe7b26cbcb4f719cb77fd6 >>> .be88925bf6.wbe%40email16.secureserver.net%3E I've prepared stupid patch to create temporary files in WC, instead of .svn/tmp and it seems working fine. -1. This leaves us with no reliable way to clean up the working copy in case of an aborted operation. There should be a better way for managing ACLs on windows that does not require us to mess up the working copy. I'm perfectly happy with just documenting that we don't support different ACLs for .svn and the rest of the WC, at least for now. >>> Please note that problem reported is not about inherited ACL: now >>> users got NOT_INDEXED attribute on all WC files, because .svn marked >>> to by not indexed by Windows Search and tools like that. >> >> >> I'm working on a better patch for this, that doesn't have this problem and >> will improve performance on the pristine store operations as well. >> >> But since when is this a huge problem? We applied this setting since 1.6 >> if I remember correctly... I'm more surprised that you didn't know about >> this? > > > Instead of setting the attributes after moving the files, how about creating > a new folder "wctemp" in the .svn folder and set the attribute on that > folder. Then use that folder to create the temp files which are intended for > moving to the working copy? That way temp files don't have to be created > inside the working copy. > Because user may change "not indexed" attribute of WC folder and children should inherit it. -- Ivan Zhakov
Re: svn commit: r1577117 - /subversion/trunk/tools/dev/unix-build/Makefile.svn
On 3/13/14, 6:40 AM, Stefan Sperling wrote: >> (FWIW, the fact that the bb-openbsd bot uses a different script from >> other bots is also a problem, but IIUC Ben is working on addressing that.) > > I'm quite happy that I have reproducible builds on OpenBSD and if necessary > other *nix-like systems with full control and automation. > > If Ben invents something similar that's great. > I believe that diversity in the buildfarm doesn't hurt. Branko's referring to my project to try and cleanup up the buildbot builders to get them have some consistency. By that I mean the following: * Similar build bot setup patterns, I'd like to see the setup in the master config be nearly identical for all the builders. This doesn't mean all the bots need to do the same tests or use the same dependencies. Each builder is still going to have all of their own scripts. * Have all the builders get their scripts from Subversion (trunk/tools/buildbot/slaves) in an automated way, allowing any of us to disable tests or tweak the testing. I completely agree that the build should be repeatable, we could get some of that by using separate installs of the dependencies just for the bot, but I think we want to test OS provided dependencies as well. So at least some of the bots, reproducibility comes down to someone not screwing with the installed dependencies.
Re: Subversion checked-out files not indexed in Windows search
On 13.03.2014 14:14, Bert Huijben wrote: -Original Message- From: Ivan Zhakov [mailto:i...@visualsvn.com] Sent: donderdag 13 maart 2014 13:56 To: Branko Čibej Cc: Subversion Development Subject: Re: Subversion checked-out files not indexed in Windows search On 13 March 2014 16:46, Branko Čibej wrote: On 13.03.2014 13:37, Ivan Zhakov wrote: On 12 March 2014 18:17, Gareth McCaughan wrote: Ivan Zhakov wrote: It looks like serious issue. Could you please file issue in Subversion issue tracker: http://subversion.tigris.org/issues Done. Issue #4478. Gareth, thanks a lot! It seems we have second reason to create temporary files in target WC directory, instead of .svn/tmp. Another problem we had before is inherited ACL on Windows discussed year ago: http://mail-archives.apache.org/mod_mbox/subversion- dev/201309.mbox/%3C20130928110059.d1bb8d007dfe7b26cbcb4f719cb77fd6 .be88925bf6.wbe%40email16.secureserver.net%3E I've prepared stupid patch to create temporary files in WC, instead of .svn/tmp and it seems working fine. -1. This leaves us with no reliable way to clean up the working copy in case of an aborted operation. There should be a better way for managing ACLs on windows that does not require us to mess up the working copy. I'm perfectly happy with just documenting that we don't support different ACLs for .svn and the rest of the WC, at least for now. Please note that problem reported is not about inherited ACL: now users got NOT_INDEXED attribute on all WC files, because .svn marked to by not indexed by Windows Search and tools like that. I'm working on a better patch for this, that doesn't have this problem and will improve performance on the pristine store operations as well. But since when is this a huge problem? We applied this setting since 1.6 if I remember correctly... I'm more surprised that you didn't know about this? Instead of setting the attributes after moving the files, how about creating a new folder "wctemp" in the .svn folder and set the attribute on that folder. Then use that folder to create the temp files which are intended for moving to the working copy? That way temp files don't have to be created inside the working copy. Stefan -- ___ oo // \\ "De Chelonian Mobile" (_,\/ \_/ \ TortoiseSVN \ \_/_\_/>The coolest interface to (Sub)version control /_/ \_\ http://tortoisesvn.net
Re: -lintl in SVN_INTL_LIBS and LIBS
Stefan Sperling writes: > On Thu, Mar 13, 2014 at 04:16:17PM -, s...@apache.org wrote: >> Author: stsp >> Date: Thu Mar 13 16:16:16 2014 >> New Revision: 1577223 >> -AC_SEARCH_LIBS(bindtextdomain, [intl], [], >> +AC_SEARCH_LIBS(bindtextdomain, [intl], >> + [ >> +SVN_INTL_LIBS="-lintl" That's not correct. AC_SEARCH_LIBS will start with no libs and will only go on to check libintl if it doesn't find the symbol. At this point we don't know whether libintl was needed or whether it worked without. I'm still not really sure why we are trying to set SVN_INTL_LIBS at all. Why is LIBS not enough? >> + ], >> [ >> enable_nls="no" >> ]) >> @@ -702,9 +705,7 @@ if test "$enable_nls" = "yes"; then >>AC_SEARCH_LIBS(bindtextdomain, [intl], >> [ >>enable_nls="yes" >> - # This is here so that -liconv ends up in LIBS >> - # if it worked with -liconv. >> - AC_CHECK_LIB(iconv, libiconv_open) >> + SVN_INTL_LIBS="-lintl -liconv" >> ], >> [ >>AC_MSG_WARN([bindtextdomain() not found. Disabling >> NLS.]) >> @@ -720,6 +721,8 @@ if test "$enable_nls" = "yes"; then >>fi >> fi >> >> +AC_SUBST(SVN_INTL_LIBS) >> + >> AH_BOTTOM([ >> /* Indicate to translators that string X should be translated. Do not look >> up the translation at run time; just expand to X. This macro is suitable >> > -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*
Re: -lintl in SVN_INTL_LIBS and LIBS
On 13.03.2014 17:22, Stefan Sperling wrote: > On Thu, Mar 13, 2014 at 04:16:17PM -, s...@apache.org wrote: >> Author: stsp >> Date: Thu Mar 13 16:16:16 2014 >> New Revision: 1577223 >> >> URL: http://svn.apache.org/r1577223 >> Log: >> Add libintl link flags to SVN_INTL_LIBS on *nix builds. >> >> The SVN_INTL_LIBS variable was referred to but never defined. >> >> * Makefile.in: Define SVN_INTL_LIBS. >> >> * configure.ac: Set SVN_INTL_LIBS to the linker flags required >>to link to libintl and export the value of SVN_INTL_LIBS >>to the Makefile. > A side-effect of this change is that -lintl now appears in > both SVN_INTL_LIBS and LIBS. It is in LIBS because AC_SEARCH_LIBS > insits on putting it there. > > Do we care enough to somehow work around that? Or do we just live > with potential redundant -lintl linker flags? We should try to reset LIBS during AC_SEARCH_LIBS for gettext & co. IIRC, we do something similar for SQLite. -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
-lintl in SVN_INTL_LIBS and LIBS (was: Re: svn commit: r1577223 - in /subversion/trunk: Makefile.in configure.ac)
On Thu, Mar 13, 2014 at 04:16:17PM -, s...@apache.org wrote: > Author: stsp > Date: Thu Mar 13 16:16:16 2014 > New Revision: 1577223 > > URL: http://svn.apache.org/r1577223 > Log: > Add libintl link flags to SVN_INTL_LIBS on *nix builds. > > The SVN_INTL_LIBS variable was referred to but never defined. > > * Makefile.in: Define SVN_INTL_LIBS. > > * configure.ac: Set SVN_INTL_LIBS to the linker flags required >to link to libintl and export the value of SVN_INTL_LIBS >to the Makefile. A side-effect of this change is that -lintl now appears in both SVN_INTL_LIBS and LIBS. It is in LIBS because AC_SEARCH_LIBS insits on putting it there. Do we care enough to somehow work around that? Or do we just live with potential redundant -lintl linker flags? > Modified: > subversion/trunk/Makefile.in > subversion/trunk/configure.ac > > Modified: subversion/trunk/Makefile.in > URL: > http://svn.apache.org/viewvc/subversion/trunk/Makefile.in?rev=1577223&r1=1577222&r2=1577223&view=diff > == > --- subversion/trunk/Makefile.in (original) > +++ subversion/trunk/Makefile.in Thu Mar 13 16:16:16 2014 > @@ -48,6 +48,7 @@ SVN_GPG_AGENT_LIBS = @SVN_GPG_AGENT_LIBS > SVN_GNOME_KEYRING_LIBS = @SVN_GNOME_KEYRING_LIBS@ > SVN_KWALLET_LIBS = @SVN_KWALLET_LIBS@ > SVN_MAGIC_LIBS = @SVN_MAGIC_LIBS@ > +SVN_INTL_LIBS = @SVN_INTL_LIBS@ > SVN_SASL_LIBS = @SVN_SASL_LIBS@ > SVN_SERF_LIBS = @SVN_SERF_LIBS@ > SVN_SQLITE_LIBS = @SVN_SQLITE_LIBS@ > > Modified: subversion/trunk/configure.ac > URL: > http://svn.apache.org/viewvc/subversion/trunk/configure.ac?rev=1577223&r1=1577222&r2=1577223&view=diff > == > --- subversion/trunk/configure.ac (original) > +++ subversion/trunk/configure.ac Thu Mar 13 16:16:16 2014 > @@ -690,7 +690,10 @@ if test "$enable_nls" = "yes"; then >AC_PATH_PROG(MSGMERGE, msgmerge, none) >AC_PATH_PROG(XGETTEXT, xgettext, none) >if test "$MSGFMT" != "none"; then > -AC_SEARCH_LIBS(bindtextdomain, [intl], [], > +AC_SEARCH_LIBS(bindtextdomain, [intl], > + [ > +SVN_INTL_LIBS="-lintl" > + ], > [ > enable_nls="no" > ]) > @@ -702,9 +705,7 @@ if test "$enable_nls" = "yes"; then >AC_SEARCH_LIBS(bindtextdomain, [intl], > [ >enable_nls="yes" > - # This is here so that -liconv ends up in LIBS > - # if it worked with -liconv. > - AC_CHECK_LIB(iconv, libiconv_open) > + SVN_INTL_LIBS="-lintl -liconv" > ], > [ >AC_MSG_WARN([bindtextdomain() not found. Disabling > NLS.]) > @@ -720,6 +721,8 @@ if test "$enable_nls" = "yes"; then >fi > fi > > +AC_SUBST(SVN_INTL_LIBS) > + > AH_BOTTOM([ > /* Indicate to translators that string X should be translated. Do not look > up the translation at run time; just expand to X. This macro is suitable >
RE: SVN_INTL_LIBS is not defined
> -Original Message-
> From: 'Stefan Sperling' [mailto:s...@elego.de]
> Sent: donderdag 13 maart 2014 14:34
> To: Bert Huijben
> Cc: 'Branko Čibej'; dev@subversion.apache.org
> Subject: Re: SVN_INTL_LIBS is not defined
>
> On Thu, Mar 13, 2014 at 01:19:18PM +0100, Bert Huijben wrote:
> > It is at least used by the Windows build for dependency tracking. It
uses
> $(SVN_*_LIBS) as pointer to dependency definitions by parsing this
> argument.
>
> Can you show me files in which it is used?
build/generator/gen_win.py has a line
for elib in re.findall('\$\(SVN_([^\)]*)_LIBS\)', dep.external_lib):
(currently line 892)
> > Perhaps the value should be properly defined on !Windows as well instead
> of handling it magically in several scripts.
>
> Sure. We could move -lint into SVN_INTL_LIBS instead of LIBS.
> Perhaps that was the intention in the first place.
Bert
Re: svn commit: r1577117 - /subversion/trunk/tools/dev/unix-build/Makefile.svn
On Thu, Mar 13, 2014 at 01:34:51PM +0100, Branko Čibej wrote: > On 13.03.2014 12:42, s...@apache.org wrote: > > Author: stsp > > Date: Thu Mar 13 11:42:08 2014 > > New Revision: 1577117 > > > > URL: http://svn.apache.org/r1577117 > > Log: > > * tools/dev/unix-build/Makefile.svn: Add gettext support to my custom > >build script, which is also used on the bb-openbsd bot. My own svn > >development builds now support i18n so I can test related code paths. > > I'm frankly not thrilled by the existence of "your own build script." > How on earth do we know that what works for you will work for the rest > of us who use the standard "autogen.sh; configure; make" sequence? I want to control the set of dependencies independently from what the operating system provides. I want gdb traces into dependencies with debug symbols. I want to type 'make', not all the crazy commands that the Makefile automates. I was maintaining this Makefile outside of our repository for a long time. Some years ago Hyrum suggested that I move it into our repo in case it is useful to someone. If you're not happy with that I can move it elsewhere. > (FWIW, the fact that the bb-openbsd bot uses a different script from > other bots is also a problem, but IIUC Ben is working on addressing that.) I'm quite happy that I have reproducible builds on OpenBSD and if necessary other *nix-like systems with full control and automation. If Ben invents something similar that's great. I believe that diversity in the buildfarm doesn't hurt.
Re: SVN_INTL_LIBS is not defined
On Thu, Mar 13, 2014 at 01:19:18PM +0100, Bert Huijben wrote: > It is at least used by the Windows build for dependency tracking. It uses > $(SVN_*_LIBS) as pointer to dependency definitions by parsing this argument. Can you show me files in which it is used? > Perhaps the value should be properly defined on !Windows as well instead of > handling it magically in several scripts. Sure. We could move -lint into SVN_INTL_LIBS instead of LIBS. Perhaps that was the intention in the first place.
Re: svn commit: r1577144 - /subversion/trunk/subversion/libsvn_ra/compat.c
On 13 March 2014 17:13, Branko Čibej wrote:
> On 13.03.2014 13:53, i...@apache.org wrote:
>
> Author: ivan
> Date: Thu Mar 13 12:53:40 2014
> New Revision: 1577144
>
> URL: http://svn.apache.org/r1577144
> Log:
> Fix problem exposed by r1577079.
>
> * subversion/libsvn_ra/compat.c
> (svn_ra__locations_from_log): Make a copy of constant apr_array_header_t
>argument before sorting it.
>
>
> [...]
>
>
> @@ -337,10 +338,11 @@ svn_ra__locations_from_log(svn_ra_sessio
>/* Figure out the youngest and oldest revs (amongst the set of
> requested revisions + the peg revision) so we can avoid
> unnecessary log parsing. */
> - svn_sort__array(location_revisions, compare_revisions);
> - oldest_requested = APR_ARRAY_IDX(location_revisions, 0, svn_revnum_t);
> - youngest_requested = APR_ARRAY_IDX(location_revisions,
> - location_revisions->nelts - 1,
> + sorted_location_revisions = apr_array_copy(pool, location_revisions);
> + svn_sort__array(sorted_location_revisions, compare_revisions);
> + oldest_requested = APR_ARRAY_IDX(sorted_location_revisions, 0,
> svn_revnum_t);
> + youngest_requested = APR_ARRAY_IDX(sorted_location_revisions,
> + sorted_location_revisions->nelts - 1,
> svn_revnum_t);
>youngest = peg_revision;
>youngest = (oldest_requested > youngest) ? oldest_requested : youngest;
> @@ -352,7 +354,7 @@ svn_ra__locations_from_log(svn_ra_sessio
>/* Populate most of our log receiver baton structure. */
>lrb.kind = kind;
>lrb.last_path = fs_path;
> - lrb.location_revisions = apr_array_copy(pool, location_revisions);
> + lrb.location_revisions = apr_array_copy(pool, sorted_location_revisions);
>
>
> So now you've copied the array twice?
>
Yes, I do. Because lrb.locations_revisions will be modified by
svn_ra_get_log3() callback, while we need unmodified and sorted
location revisions if the received log information did not cover any
of the requested revisions:
[[[
if (! lrb.peg_path)
lrb.peg_path = lrb.last_path;
if (lrb.last_path)
{
int i;
for (i = 0; i < sorted_location_revisions->nelts; i++)
{
svn_revnum_t rev = APR_ARRAY_IDX(sorted_location_revisions, i,
svn_revnum_t);
if (! apr_hash_get(locations, &rev, sizeof(rev)))
apr_hash_set(locations, apr_pmemdup(pool, &rev, sizeof(rev)),
sizeof(rev), apr_pstrdup(pool, lrb.last_path));
}
}
]]]
So I decided to just copy it twice given that this is fallback code
for older servers and don't covered by our test suite.
--
Ivan Zhakov
RE: Subversion checked-out files not indexed in Windows search
> -Original Message- > From: Ivan Zhakov [mailto:i...@visualsvn.com] > Sent: donderdag 13 maart 2014 13:56 > To: Branko Čibej > Cc: Subversion Development > Subject: Re: Subversion checked-out files not indexed in Windows search > > On 13 March 2014 16:46, Branko Čibej wrote: > > On 13.03.2014 13:37, Ivan Zhakov wrote: > > > > On 12 March 2014 18:17, Gareth McCaughan > > wrote: > > > > Ivan Zhakov wrote: > > > > It looks like serious issue. Could you please file issue in Subversion > > issue tracker: http://subversion.tigris.org/issues > > > > Done. Issue #4478. > > > > Gareth, thanks a lot! > > > > It seems we have second reason to create temporary files in target WC > > directory, instead of .svn/tmp. Another problem we had before is > > inherited ACL on Windows discussed year ago: > > http://mail-archives.apache.org/mod_mbox/subversion- > dev/201309.mbox/%3C20130928110059.d1bb8d007dfe7b26cbcb4f719cb77fd6 > .be88925bf6.wbe%40email16.secureserver.net%3E > > > > I've prepared stupid patch to create temporary files in WC, instead of > > .svn/tmp and it seems working fine. > > > > > > -1. This leaves us with no reliable way to clean up the working copy in case > > of an aborted operation. > > > > There should be a better way for managing ACLs on windows that does not > > require us to mess up the working copy. I'm perfectly happy with just > > documenting that we don't support different ACLs for .svn and the rest of > > the WC, at least for now. > > > Please note that problem reported is not about inherited ACL: now > users got NOT_INDEXED attribute on all WC files, because .svn marked > to by not indexed by Windows Search and tools like that. I'm working on a better patch for this, that doesn't have this problem and will improve performance on the pristine store operations as well. But since when is this a huge problem? We applied this setting since 1.6 if I remember correctly... I'm more surprised that you didn't know about this? Bert
Re: svn commit: r1577144 - /subversion/trunk/subversion/libsvn_ra/compat.c
On 13.03.2014 13:53, i...@apache.org wrote: > Author: ivan > Date: Thu Mar 13 12:53:40 2014 > New Revision: 1577144 > > URL: http://svn.apache.org/r1577144 > Log: > Fix problem exposed by r1577079. > > * subversion/libsvn_ra/compat.c > (svn_ra__locations_from_log): Make a copy of constant apr_array_header_t >argument before sorting it. [...] > @@ -337,10 +338,11 @@ svn_ra__locations_from_log(svn_ra_sessio >/* Figure out the youngest and oldest revs (amongst the set of > requested revisions + the peg revision) so we can avoid > unnecessary log parsing. */ > - svn_sort__array(location_revisions, compare_revisions); > - oldest_requested = APR_ARRAY_IDX(location_revisions, 0, svn_revnum_t); > - youngest_requested = APR_ARRAY_IDX(location_revisions, > - location_revisions->nelts - 1, > + sorted_location_revisions = apr_array_copy(pool, location_revisions); > + svn_sort__array(sorted_location_revisions, compare_revisions); > + oldest_requested = APR_ARRAY_IDX(sorted_location_revisions, 0, > svn_revnum_t); > + youngest_requested = APR_ARRAY_IDX(sorted_location_revisions, > + sorted_location_revisions->nelts - 1, > svn_revnum_t); >youngest = peg_revision; >youngest = (oldest_requested > youngest) ? oldest_requested : youngest; > @@ -352,7 +354,7 @@ svn_ra__locations_from_log(svn_ra_sessio >/* Populate most of our log receiver baton structure. */ >lrb.kind = kind; >lrb.last_path = fs_path; > - lrb.location_revisions = apr_array_copy(pool, location_revisions); > + lrb.location_revisions = apr_array_copy(pool, sorted_location_revisions); So now you've copied the array twice? -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
Re: Subversion checked-out files not indexed in Windows search
On 13.03.2014 13:55, Ivan Zhakov wrote: > On 13 March 2014 16:46, Branko Čibej wrote: >> On 13.03.2014 13:37, Ivan Zhakov wrote: >> >> On 12 March 2014 18:17, Gareth McCaughan >> wrote: >> >> Ivan Zhakov wrote: >> >> It looks like serious issue. Could you please file issue in Subversion >> issue tracker: http://subversion.tigris.org/issues >> >> Done. Issue #4478. >> >> Gareth, thanks a lot! >> >> It seems we have second reason to create temporary files in target WC >> directory, instead of .svn/tmp. Another problem we had before is >> inherited ACL on Windows discussed year ago: >> http://mail-archives.apache.org/mod_mbox/subversion-dev/201309.mbox/%3C20130928110059.d1bb8d007dfe7b26cbcb4f719cb77fd6.be88925bf6.wbe%40email16.secureserver.net%3E >> >> I've prepared stupid patch to create temporary files in WC, instead of >> .svn/tmp and it seems working fine. >> >> >> -1. This leaves us with no reliable way to clean up the working copy in case >> of an aborted operation. >> >> There should be a better way for managing ACLs on windows that does not >> require us to mess up the working copy. I'm perfectly happy with just >> documenting that we don't support different ACLs for .svn and the rest of >> the WC, at least for now. >> > Please note that problem reported is not about inherited ACL: now > users got NOT_INDEXED attribute on all WC files, because .svn marked > to by not indexed by Windows Search and tools like that. I understand that; it simply means that when we install a file from .svn/tmp into the working copy proper, we have to change that attribute; either before or after the file is moved into place. See, e.g., SetFileInformationByHandle with FILE_BASIC_INFO, or SetFileAttributes. -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
Re: Subversion checked-out files not indexed in Windows search
On 13 March 2014 16:46, Branko Čibej wrote: > On 13.03.2014 13:37, Ivan Zhakov wrote: > > On 12 March 2014 18:17, Gareth McCaughan > wrote: > > Ivan Zhakov wrote: > > It looks like serious issue. Could you please file issue in Subversion > issue tracker: http://subversion.tigris.org/issues > > Done. Issue #4478. > > Gareth, thanks a lot! > > It seems we have second reason to create temporary files in target WC > directory, instead of .svn/tmp. Another problem we had before is > inherited ACL on Windows discussed year ago: > http://mail-archives.apache.org/mod_mbox/subversion-dev/201309.mbox/%3C20130928110059.d1bb8d007dfe7b26cbcb4f719cb77fd6.be88925bf6.wbe%40email16.secureserver.net%3E > > I've prepared stupid patch to create temporary files in WC, instead of > .svn/tmp and it seems working fine. > > > -1. This leaves us with no reliable way to clean up the working copy in case > of an aborted operation. > > There should be a better way for managing ACLs on windows that does not > require us to mess up the working copy. I'm perfectly happy with just > documenting that we don't support different ACLs for .svn and the rest of > the WC, at least for now. > Please note that problem reported is not about inherited ACL: now users got NOT_INDEXED attribute on all WC files, because .svn marked to by not indexed by Windows Search and tools like that. -- Ivan Zhakov CTO | VisualSVN | http://www.visualsvn.com
Re: Subversion checked-out files not indexed in Windows search
On 13.03.2014 13:37, Ivan Zhakov wrote: > On 12 March 2014 18:17, Gareth McCaughan > wrote: >> Ivan Zhakov wrote: >> >>> It looks like serious issue. Could you please file issue in Subversion >>> issue tracker: http://subversion.tigris.org/issues >> Done. Issue #4478. >> > Gareth, thanks a lot! > > It seems we have second reason to create temporary files in target WC > directory, instead of .svn/tmp. Another problem we had before is > inherited ACL on Windows discussed year ago: > http://mail-archives.apache.org/mod_mbox/subversion-dev/201309.mbox/%3C20130928110059.d1bb8d007dfe7b26cbcb4f719cb77fd6.be88925bf6.wbe%40email16.secureserver.net%3E > > I've prepared stupid patch to create temporary files in WC, instead of > .svn/tmp and it seems working fine. -1. This leaves us with no reliable way to clean up the working copy in case of an aborted operation. There should be a better way for managing ACLs on windows that does not require us to mess up the working copy. I'm perfectly happy with just documenting that we don't support different ACLs for .svn and the rest of the WC, at least for now. -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
Re: Subversion checked-out files not indexed in Windows search
On 12 March 2014 18:17, Gareth McCaughan
wrote:
> Ivan Zhakov wrote:
>
>> It looks like serious issue. Could you please file issue in Subversion
>> issue tracker: http://subversion.tigris.org/issues
>
> Done. Issue #4478.
>
Gareth, thanks a lot!
It seems we have second reason to create temporary files in target WC
directory, instead of .svn/tmp. Another problem we had before is
inherited ACL on Windows discussed year ago:
http://mail-archives.apache.org/mod_mbox/subversion-dev/201309.mbox/%3C20130928110059.d1bb8d007dfe7b26cbcb4f719cb77fd6.be88925bf6.wbe%40email16.secureserver.net%3E
I've prepared stupid patch to create temporary files in WC, instead of
.svn/tmp and it seems working fine.
--
Ivan Zhakov
Index: subversion/libsvn_wc/workqueue.c
===
--- subversion/libsvn_wc/workqueue.c(revision 1577065)
+++ subversion/libsvn_wc/workqueue.c(working copy)
@@ -476,6 +476,7 @@
const svn_checksum_t *checksum;
apr_hash_t *props;
apr_time_t changed_date;
+ svn_error_t *err;
local_relpath = apr_pstrmemdup(scratch_pool, arg1->data, arg1->len);
SVN_ERR(svn_wc__db_from_relpath(&local_abspath, db, wri_abspath,
@@ -564,17 +565,32 @@
scratch_pool);
}
+ temp_dir_abspath = svn_dirent_dirname(local_abspath, scratch_pool);
+#if 0
/* Where is the Right Place to put a temp file in this working copy? */
SVN_ERR(svn_wc__db_temp_wcroot_tempdir(&temp_dir_abspath,
db, wcroot_abspath,
scratch_pool, scratch_pool));
+#endif
/* Translate to a temporary file. We don't want the user seeing a partial
file, nor let them muck with it while we translate. We may also need to
get its TRANSLATED_SIZE before the user can monkey it. */
- SVN_ERR(svn_stream__create_for_install(&dst_stream, temp_dir_abspath,
- scratch_pool, scratch_pool));
+ err = svn_stream__create_for_install(&dst_stream, temp_dir_abspath,
+ scratch_pool, scratch_pool);
+ if (err && APR_STATUS_IS_ENOENT(err->apr_err))
+{
+ svn_error_clear(err);
+ SVN_ERR(svn_io_make_dir_recursively(temp_dir_abspath, scratch_pool));
+ SVN_ERR(svn_stream__create_for_install(&dst_stream, temp_dir_abspath,
+ scratch_pool, scratch_pool));
+}
+ else if (err)
+{
+ return svn_error_trace(err);
+}
+
/* Copy from the source to the dest, translating as we go. This will also
close both streams. */
SVN_ERR(svn_stream_copy3(src_stream, dst_stream,
Re: svn commit: r1577117 - /subversion/trunk/tools/dev/unix-build/Makefile.svn
On 13.03.2014 12:42, s...@apache.org wrote: > Author: stsp > Date: Thu Mar 13 11:42:08 2014 > New Revision: 1577117 > > URL: http://svn.apache.org/r1577117 > Log: > * tools/dev/unix-build/Makefile.svn: Add gettext support to my custom >build script, which is also used on the bb-openbsd bot. My own svn >development builds now support i18n so I can test related code paths. I'm frankly not thrilled by the existence of "your own build script." How on earth do we know that what works for you will work for the rest of us who use the standard "autogen.sh; configure; make" sequence? (FWIW, the fact that the bb-openbsd bot uses a different script from other bots is also a problem, but IIUC Ben is working on addressing that.) -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
RE: SVN_INTL_LIBS is not defined (was: Re: svn commit: r1574710 - in /subversion/trunk: ./ build/generator/ ...)
> -Original Message- > From: Stefan Sperling [mailto:s...@elego.de] > Sent: donderdag 13 maart 2014 12:48 > To: Branko Čibej; dev@subversion.apache.org > Subject: SVN_INTL_LIBS is not defined (was: Re: svn commit: r1574710 - in > /subversion/trunk: ./ build/generator/ ...) > > On Thu, Mar 06, 2014 at 01:00:17PM +0100, Stefan Sperling wrote: > > On Thu, Mar 06, 2014 at 10:34:33AM +0100, Branko Čibej wrote: > > > Of course we use libintl on Unix, and we can't assume it's a system > > > library. It's not on OSX, which is very much Unix, for example. > > > > I couldn't find any definition for $(SVN_INTL_LIBS), referenced in > > build.conf here: > > > > [intl] > > type = lib > > external-lib = $(SVN_INTL_LIBS) > > > > This led me to the conclusion that $(SVN_INTL_LIBS) is not defined > > on *nix. But perhaps that conclusion is wrong, and I'm supposed to > > see such a definition somewhere? Or is it only defined in some > > circumstances? > > I found that -lintl gets added to $LIBS if I enable gettext support. > And that, indeed, libintl is a separate library. > > However, I still don't understand what $(SVN_INTL_LIBS) is for. > > Is SVN_INTL_LIBS used on any platform? If not, I'd like to remove it because > it interferes with generation of pkg-config files. Otherwise, I'll need to > know in which circumstances it is being used. > > $ grep -r SVN_INTL_LIBS * > build-outputs.mk: cd subversion/libsvn_subr && $(LINK_LIB) > $(libsvn_subr_LDFLAGS) -o libsvn_subr-1.la $(LT_NO_UNDEFINED) > $(libsvn_subr_OBJECTS) $(SVN_APRUTIL_LIBS) $(SVN_APR_LIBS) > $(SVN_XML_LIBS) $(SVN_ZLIB_LIBS) $(SVN_APR_MEMCACHE_LIBS) > $(SVN_SQLITE_LIBS) $(SVN_MAGIC_LIBS) $(SVN_INTL_LIBS) $(LIBS) > build.conf:external-lib = $(SVN_INTL_LIBS) > grep: subversion/tests/cmdline/svn-test-work: No such file or directory > $ grep -- -lintl Makefile > SVN_GNOME_KEYRING_LIBS = -L/usr/local/lib -lgnome-keyring -lglib-2.0 - > lintl > LIBS = -lintl > $ It is at least used by the Windows build for dependency tracking. It uses $(SVN_*_LIBS) as pointer to dependency definitions by parsing this argument. Perhaps the value should be properly defined on !Windows as well instead of handling it magically in several scripts. Bert
Re: svn commit: r1577082 - /subversion/trunk/subversion/tests/cmdline/special_tests.py
"Bert Huijben" writes: > The WC-NG idea was to stop creating files for symlinks (aka special) and > introduce a proper symlink type in the working copy (and via editor v2), > which would still be handled via the special property trick on commit/update > when using editor v1. That's not what we have today. > We never really supported multi line svn:special files or really anything > except symlinks... and the idea back then was to never start supporting > those cases either. If the svn:special file has content that that does not represent a link we chose to put an ordinary file containing the pristine content into the working copy. Given that choice it seems ridiculous for the file to contain only part of the pristine content. I think it is much more sensible for the file to contain the whole content and I don't see how that would cause a problem. -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*
RE: svn commit: r1577082 - /subversion/trunk/subversion/tests/cmdline/special_tests.py
> -Original Message- > From: Philip Martin [mailto:philip.mar...@wandisco.com] > Sent: donderdag 13 maart 2014 12:32 > To: Bert Huijben > Cc: dev@subversion.apache.org > Subject: Re: svn commit: r1577082 - > /subversion/trunk/subversion/tests/cmdline/special_tests.py > > "Bert Huijben" writes: > > >> -Original Message- > >> From: phi...@apache.org [mailto:phi...@apache.org] > >> Sent: donderdag 13 maart 2014 11:13 > >> To: comm...@subversion.apache.org > >> Subject: svn commit: r1577082 - > >> /subversion/trunk/subversion/tests/cmdline/special_tests.py > >> > >> Author: philip > >> Date: Thu Mar 13 10:12:50 2014 > >> New Revision: 1577082 > >> > >> URL: http://svn.apache.org/r1577082 > >> Log: > >> Add an XFAIL regression test for issue 4479, multiline svn:special > truncated. > >> > >> * subversion/tests/cmdline/special_tests.py > >> (multiline_special): New test. > >> (test_list): Add new test. > > > > As far as I can tell we handled this limitation as 'as designed' when > > implementing WC-NG. > > > > I don't think this is something we can really 'fix', as older clients > > will just break things when they would find such a 'symlink'. > > > > The idea back then (ask gstein :-) was to move away from using a > > single magic property for this, if we ever wanted to support more > > 'special' files. > > If the pristine file for an svn:special is "foo\nbar\n" we currently > create a working file containing "foo". Irrespective of future changes > I think it would be better if the working file contained "foo\nbar\n". > Are you saying that is not a good idea? In what way will old clients > break? The WC-NG idea was to stop creating files for symlinks (aka special) and introduce a proper symlink type in the working copy (and via editor v2), which would still be handled via the special property trick on commit/update when using editor v1. We never really supported multi line svn:special files or really anything except symlinks... and the idea back then was to never start supporting those cases either. Bert
SVN_INTL_LIBS is not defined (was: Re: svn commit: r1574710 - in /subversion/trunk: ./ build/generator/ ...)
On Thu, Mar 06, 2014 at 01:00:17PM +0100, Stefan Sperling wrote: > On Thu, Mar 06, 2014 at 10:34:33AM +0100, Branko Čibej wrote: > > Of course we use libintl on Unix, and we can't assume it's a system > > library. It's not on OSX, which is very much Unix, for example. > > I couldn't find any definition for $(SVN_INTL_LIBS), referenced in > build.conf here: > > [intl] > type = lib > external-lib = $(SVN_INTL_LIBS) > > This led me to the conclusion that $(SVN_INTL_LIBS) is not defined > on *nix. But perhaps that conclusion is wrong, and I'm supposed to > see such a definition somewhere? Or is it only defined in some > circumstances? I found that -lintl gets added to $LIBS if I enable gettext support. And that, indeed, libintl is a separate library. However, I still don't understand what $(SVN_INTL_LIBS) is for. Is SVN_INTL_LIBS used on any platform? If not, I'd like to remove it because it interferes with generation of pkg-config files. Otherwise, I'll need to know in which circumstances it is being used. $ grep -r SVN_INTL_LIBS * build-outputs.mk: cd subversion/libsvn_subr && $(LINK_LIB) $(libsvn_subr_LDFLAGS) -o libsvn_subr-1.la $(LT_NO_UNDEFINED) $(libsvn_subr_OBJECTS) $(SVN_APRUTIL_LIBS) $(SVN_APR_LIBS) $(SVN_XML_LIBS) $(SVN_ZLIB_LIBS) $(SVN_APR_MEMCACHE_LIBS) $(SVN_SQLITE_LIBS) $(SVN_MAGIC_LIBS) $(SVN_INTL_LIBS) $(LIBS) build.conf:external-lib = $(SVN_INTL_LIBS) grep: subversion/tests/cmdline/svn-test-work: No such file or directory $ grep -- -lintl Makefile SVN_GNOME_KEYRING_LIBS = -L/usr/local/lib -lgnome-keyring -lglib-2.0 -lintl LIBS = -lintl $
Re: svn commit: r1577082 - /subversion/trunk/subversion/tests/cmdline/special_tests.py
Philip Martin writes:
> "Bert Huijben" writes:
>
>>> -Original Message-
>>> From: phi...@apache.org [mailto:phi...@apache.org]
>>> Sent: donderdag 13 maart 2014 11:13
>>> To: comm...@subversion.apache.org
>>> Subject: svn commit: r1577082 -
>>> /subversion/trunk/subversion/tests/cmdline/special_tests.py
>>>
>>> Author: philip
>>> Date: Thu Mar 13 10:12:50 2014
>>> New Revision: 1577082
>>>
>>> URL: http://svn.apache.org/r1577082
>>> Log:
>>> Add an XFAIL regression test for issue 4479, multiline svn:special
>>> truncated.
>>>
>>> * subversion/tests/cmdline/special_tests.py
>>> (multiline_special): New test.
>>> (test_list): Add new test.
>>
>> As far as I can tell we handled this limitation as 'as designed' when
>> implementing WC-NG.
>>
>> I don't think this is something we can really 'fix', as older clients
>> will just break things when they would find such a 'symlink'.
>>
>> The idea back then (ask gstein :-) was to move away from using a
>> single magic property for this, if we ever wanted to support more
>> 'special' files.
>
> If the pristine file for an svn:special is "foo\nbar\n" we currently
> create a working file containing "foo". Irrespective of future changes
> I think it would be better if the working file contained "foo\nbar\n".
> Are you saying that is not a good idea? In what way will old clients
> break?
This is fix I was intending. Are you saying this is a bad idea?
Index: subversion/libsvn_subr/subst.c
===
--- subversion/libsvn_subr/subst.c (revision 1577082)
+++ subversion/libsvn_subr/subst.c (working copy)
@@ -1713,23 +1713,27 @@ create_special_file_from_stream(svn_stream_t *sour
}
/* If nothing else worked, write out the internal representation to
- a file that can be edited by the user.
-
- ### this only writes the first line!
- */
+ a file that can be edited by the user. */
if (create_using_internal_representation)
{
apr_file_t *new_file;
+ svn_stream_t *new_stream;
+
SVN_ERR(svn_io_open_unique_file3(&new_file, &dst_tmp,
svn_dirent_dirname(dst, pool),
svn_io_file_del_none,
pool, pool));
+ if (!eof)
+svn_stringbuf_appendcstr(contents, "\n");
SVN_ERR(svn_io_file_write_full(new_file,
contents->data, contents->len, NULL,
pool));
- SVN_ERR(svn_io_file_close(new_file, pool));
+ new_stream = svn_stream_from_aprfile2(new_file, FALSE, pool);
+
+ SVN_ERR(svn_stream_copy3(svn_stream_disown(source, pool), new_stream,
+ NULL, NULL, pool));
}
/* Do the atomic rename from our temporary location. */
Index: subversion/tests/cmdline/special_tests.py
===
--- subversion/tests/cmdline/special_tests.py (revision 1577082)
+++ subversion/tests/cmdline/special_tests.py (working copy)
@@ -1222,7 +1222,6 @@ def incoming_symlink_changes(sbox):
True)
#--
-@XFail()
@Issue(4479)
def multiline_special(sbox):
"multiline file with svn:special"
--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
Re: svn commit: r1577082 - /subversion/trunk/subversion/tests/cmdline/special_tests.py
"Bert Huijben" writes: >> -Original Message- >> From: phi...@apache.org [mailto:phi...@apache.org] >> Sent: donderdag 13 maart 2014 11:13 >> To: comm...@subversion.apache.org >> Subject: svn commit: r1577082 - >> /subversion/trunk/subversion/tests/cmdline/special_tests.py >> >> Author: philip >> Date: Thu Mar 13 10:12:50 2014 >> New Revision: 1577082 >> >> URL: http://svn.apache.org/r1577082 >> Log: >> Add an XFAIL regression test for issue 4479, multiline svn:special truncated. >> >> * subversion/tests/cmdline/special_tests.py >> (multiline_special): New test. >> (test_list): Add new test. > > As far as I can tell we handled this limitation as 'as designed' when > implementing WC-NG. > > I don't think this is something we can really 'fix', as older clients > will just break things when they would find such a 'symlink'. > > The idea back then (ask gstein :-) was to move away from using a > single magic property for this, if we ever wanted to support more > 'special' files. If the pristine file for an svn:special is "foo\nbar\n" we currently create a working file containing "foo". Irrespective of future changes I think it would be better if the working file contained "foo\nbar\n". Are you saying that is not a good idea? In what way will old clients break? -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*
Re: svn commit: r1577079 - in /subversion/trunk/subversion: include/private/ libsvn_client/ libsvn_delta/ libsvn_diff/ libsvn_fs_fs/ libsvn_ra/ libsvn_repos/ libsvn_subr/ libsvn_wc/ svndumpfilter/
On 13 March 2014 14:28, Bert Huijben wrote: >> >> +/* Sort APR array @a array using ordering defined by @a comparison_func. >> + * @a comparison_func is defined as for the C stdlib function qsort(). >> + */ >> +void >> +svn_sort__array(apr_array_header_t *array, >> +int (*comparison_func)(const void *, >> + const void *)); > > I think the documentation should note that the array values must be pointers > as that is how you pass the comparison function. > > There are pretty common cases where we use apr arrays with struct members, > instead of pointer to struct. (E.g. for property changes) > Why? svn_sort__array() as qsort() invoke ordering callback with a pointer to array element. It could pointer to pointer if array contains pointer or pointer to any struct. -- Ivan Zhakov CTO | VisualSVN | http://www.visualsvn.com
RE: svn commit: r1577082 - /subversion/trunk/subversion/tests/cmdline/special_tests.py
> -Original Message- > From: phi...@apache.org [mailto:phi...@apache.org] > Sent: donderdag 13 maart 2014 11:13 > To: comm...@subversion.apache.org > Subject: svn commit: r1577082 - > /subversion/trunk/subversion/tests/cmdline/special_tests.py > > Author: philip > Date: Thu Mar 13 10:12:50 2014 > New Revision: 1577082 > > URL: http://svn.apache.org/r1577082 > Log: > Add an XFAIL regression test for issue 4479, multiline svn:special truncated. > > * subversion/tests/cmdline/special_tests.py > (multiline_special): New test. > (test_list): Add new test. As far as I can tell we handled this limitation as 'as designed' when implementing WC-NG. I don't think this is something we can really 'fix', as older clients will just break things when they would find such a 'symlink'. The idea back then (ask gstein :-) was to move away from using a single magic property for this, if we ever wanted to support more 'special' files. Bert
RE: svn commit: r1577079 - in /subversion/trunk/subversion: include/private/ libsvn_client/ libsvn_delta/ libsvn_diff/ libsvn_fs_fs/ libsvn_ra/ libsvn_repos/ libsvn_subr/ libsvn_wc/ svndumpfilter/
> -Original Message- > From: i...@apache.org [mailto:i...@apache.org] > Sent: donderdag 13 maart 2014 11:00 > To: comm...@subversion.apache.org > Subject: svn commit: r1577079 - in /subversion/trunk/subversion: > include/private/ libsvn_client/ libsvn_delta/ libsvn_diff/ libsvn_fs_fs/ > libsvn_ra/ libsvn_repos/ libsvn_subr/ libsvn_wc/ svndumpfilter/ > > Author: ivan > Date: Thu Mar 13 09:59:55 2014 > New Revision: 1577079 > > URL: http://svn.apache.org/r1577079 > Log: > Add svn_sort__array() -- simple wrapper around qsort() to sort APR array > and use where applicable. > > * subversion/include/private/svn_sorts_private.h > (svn_sort__array): New declaration. > > * subversion/libsvn_subr/sorts.c > (svn_sort__array): New. > > * subversion/libsvn_client/add.c > (): Include svn_sorts_private.h. > (mkdir_urls): Use svn_sort__array(). > > * subversion/libsvn_client/commit.c > (): Include svn_sorts_private.h. > (determine_lock_targets): Use svn_sort__array(). > > * subversion/libsvn_client/commit_util.c > (): Remove stdlib.h and include svn_sorts_private.h. > (svn_client__condense_commit_items): Use svn_sort__array(). > > * subversion/libsvn_client/ra.c > (): Include svn_sorts_private.h. > (svn_client__repos_location_segments): Use svn_sort__array(). > > * subversion/libsvn_client/resolved.c > (): Remove stdlib.h and include svn_sorts_private.h. > (svn_client__resolve_conflicts): Use svn_sort__array(). > > * subversion/libsvn_delta/path_driver.c > (): Include svn_sorts_private.h. > (svn_delta_path_driver2): Use svn_sort__array(). > > * subversion/libsvn_diff/parse-diff.c > (): Include svn_sorts_private.h. > (svn_diff_parse_next_patch): Use svn_sort__array(). > > * subversion/libsvn_fs_fs/cached_data.c > (read_dir_entries): Use svn_sort__array(). > > * subversion/libsvn_fs_fs/transaction.c > (verify_locks): Use svn_sort__array(). > > * subversion/libsvn_ra/compat.c > (svn_ra__locations_from_log): Use svn_sort__array(). > > * subversion/libsvn_repos/log.c > (): Include svn_sorts_private.h. > (turn_unique_copies_into_moves, combine_mergeinfo_path_lists, >handle_merged_revisions): Use svn_sort__array(). > > * subversion/libsvn_repos/replay.c > (): Include svn_sorts_private.h. > (svn_repos__replay_ev2): Use svn_sort__array(). > > * subversion/libsvn_repos/rev_hunt.c > (): Include svn_sorts_private.h. > (find_merged_revisions): Use svn_sort__array(). > > * subversion/libsvn_subr/mergeinfo.c > (combine_with_lastrange, parse_revision_line, svn_mergeinfo_sort): Use >svn_sort__array(). > > * subversion/libsvn_wc/revert.c > (): Include svn_sorts_private.h. > (revert_restore_handle_copied_dirs): Use svn_sort__array(). > > * subversion/svndumpfilter/svndumpfilter.c > (): Include svn_sorts_private.h. > (do_filter): Use svn_sort__array(). > > Modified: > subversion/trunk/subversion/include/private/svn_sorts_private.h > subversion/trunk/subversion/libsvn_client/add.c > subversion/trunk/subversion/libsvn_client/commit.c > subversion/trunk/subversion/libsvn_client/commit_util.c > subversion/trunk/subversion/libsvn_client/ra.c > subversion/trunk/subversion/libsvn_client/resolved.c > subversion/trunk/subversion/libsvn_delta/path_driver.c > subversion/trunk/subversion/libsvn_diff/parse-diff.c > subversion/trunk/subversion/libsvn_fs_fs/cached_data.c > subversion/trunk/subversion/libsvn_fs_fs/transaction.c > subversion/trunk/subversion/libsvn_ra/compat.c > subversion/trunk/subversion/libsvn_repos/log.c > subversion/trunk/subversion/libsvn_repos/replay.c > subversion/trunk/subversion/libsvn_repos/rev_hunt.c > subversion/trunk/subversion/libsvn_subr/mergeinfo.c > subversion/trunk/subversion/libsvn_subr/sorts.c > subversion/trunk/subversion/libsvn_wc/revert.c > subversion/trunk/subversion/svndumpfilter/svndumpfilter.c > > Modified: subversion/trunk/subversion/include/private/svn_sorts_private.h > URL: > http://svn.apache.org/viewvc/subversion/trunk/subversion/include/private > /svn_sorts_private.h?rev=1577079&r1=1577078&r2=1577079&view=diff > == > > --- subversion/trunk/subversion/include/private/svn_sorts_private.h > (original) > +++ subversion/trunk/subversion/include/private/svn_sorts_private.h Thu > Mar 13 09:59:55 2014 > @@ -72,6 +72,14 @@ svn_sort__hash(apr_hash_t *ht, >const svn_sort__item_t *), > apr_pool_t *pool); > > +/* Sort APR array @a array using ordering defined by @a comparison_func. > + * @a comparison_func is defined as for the C stdlib function qsort(). > + */ > +void > +svn_sort__array(apr_array_header_t *array, > +int (*comparison_func)(const void *, > + const void *)); I think the documentation should note that the array values must be pointers as that is how yo
