Re: [PATCH] make check-ctypes-python fails when executed from non src build direction
Gavin Beau Baumanis wrote:
Ping. This thread has received no further comments.
Thanks Gavin, but in fact I did commit Noorul's patch in r1030557:
http://svn.haxx.se/dev/archive-2010-11/0059.shtml. (The thread's
subject line no longer contained '[PATCH]' by that point.)
I am not taking any further action with the duplication between setup.py
and run_ctypesgen.sh.
- Julian
On 01/11/2010, at 9:24 PM, Julian Foad wrote:
On Mon, 2010-11-01, Noorul Islam K M wrote:
* build/run_ctypesgen.sh: Use source directory as target instead of build
directory.
(cat $abs_srcdir/$cp_relpath/csvn/core/functions.py.in; \
sed -e '/^FILE =/d' $output | \
perl -pe 's{(\s+\w+)\.restype = POINTER\(svn_error_t\)}{\1.restype =
POINTER(svn_error_t)\n\1.errcheck = _svn_errcheck}' \
- ) $abs_builddir/$cp_relpath/csvn/core/functions.py
+ ) $abs_srcdir/$cp_relpath/csvn/core/functions.py
Re: [PATCH] make check-ctypes-python fails when executed from non src build direction
Thanks Julian,
Gavin Beau Baumanis
On 16/11/2010, at 9:41 PM, Julian Foad wrote:
Gavin Beau Baumanis wrote:
Ping. This thread has received no further comments.
Thanks Gavin, but in fact I did commit Noorul's patch in r1030557:
http://svn.haxx.se/dev/archive-2010-11/0059.shtml. (The thread's
subject line no longer contained '[PATCH]' by that point.)
I am not taking any further action with the duplication between setup.py
and run_ctypesgen.sh.
- Julian
On 01/11/2010, at 9:24 PM, Julian Foad wrote:
On Mon, 2010-11-01, Noorul Islam K M wrote:
* build/run_ctypesgen.sh: Use source directory as target instead of build
directory.
(cat $abs_srcdir/$cp_relpath/csvn/core/functions.py.in; \
sed -e '/^FILE =/d' $output | \
perl -pe 's{(\s+\w+)\.restype = POINTER\(svn_error_t\)}{\1.restype =
POINTER(svn_error_t)\n\1.errcheck = _svn_errcheck}' \
- ) $abs_builddir/$cp_relpath/csvn/core/functions.py
+ ) $abs_srcdir/$cp_relpath/csvn/core/functions.py
Re: [PATCH] Indentation error in swig binding
Gavin Beau Baumanis gav...@thespidernet.com writes: Just checking if there is anything left to do for this thread. Nothing more to do, thanks! -- Philip
Re: --with-ssl, --with-openssl - svn commit: r1035375 - /subversion/trunk/configure.ac
On Mon, 2010-11-15 at 17:59 +, cmpil...@apache.org wrote: Author: cmpilato Date: Mon Nov 15 17:59:39 2010 New Revision: 1035375 URL: http://svn.apache.org/viewvc?rev=1035375view=rev Log: For issue #3301 (Cannot build without OpenSSL), http://subversion.tigris.org/issues/show_bug.cgi?id=3301 add some (hopefully) helpful info to 'configure --help' output. * configure.ac Add --help information about the --with-openssl parameter, which (like --with-ssl) isn't used by Subversion itself, but by a dependent library (Serf, in this case). Also note the alternatives available (Serf for Neon, and vice-versa). Based on my understanding from this help text, I think we should rename those options to something like --with-neon-openssl --with-serf-openssl and deprecate the old names --with-openssl --with-ssl Did I get them the right way around? Ah, no - other way around. That's my point, you see :-) Makes sense? - Julian
A new 1.7 switch feature?
We seem to have given switch a new ability in 1.7, it's possible to switch a unversioned path: svnadmin create repo svn mkdir -mm file://`pwd`/repo/A svn co file://`pwd`/repo wc svn sw file://`pwd`/repo/A wc/X Now I see: svn st wc S wc/X and sqlite wc/.svn/wc.db select * from nodes 1|A|0||1|A|1|normal|||dir|()|infinity|||1|1289910810354827|pm 1||0||1||1|normal|||dir|()|infinity|||1|1289910810354827|pm 1|X|0||1|A|1|normal|||dir|()|infinity|||1|1289910810354827|pm In 1.6 the switch fails with an error that wc/X was not versioned. It is possible to make 1.6 do the switch: svn mkdir -mm file://`pwd`/repo/X svn co file://`pwd`/repo wc svn sw file://`pwd`/repo/A wc/X svn up -r1 wc That results in a similar working copy to the one obtained by switching a non-versioned node. Is this something that we should be supporting? Perhaps we should get rid of the externals code and use this instead? Yes, it appears to work for files. -- Philip
Re: [PATCH] error leak on performance branch
On Tue, Nov 16, 2010 at 09:37:53AM +1100, Gavin Beau Baumanis wrote: Hi Stefan, Just checking if there is anything remainig with this patch? I haven't noticed a committed reply or any further comments. Thanks for the reminder! stefan2 committed a very similar patch in r1033040. Stefan
RE: Translation help
-Original Message- From: hy...@hyrumwright.org [mailto:hy...@hyrumwright.org] On Behalf Of Hyrum K. Wright Sent: 15 November 2010 18:17 To: Subversion Development Subject: Translation help To any current and/or interested translators: In an effort to make translation of Subversion easier, and more complete, I've installed an instance of Pootle, a web-based translation tool. You can access it here: http://translate.hyrumwright.org/projects/svn/ -Hyrum Nice find, we're thinking of investigating it to see if it would help our internal translation efforts! My colleague Kim might help with a Danish translation, but he is busy so wouldn't be able to commit fully to it - so, would it make sense to put a translation project for Danish on that site so he could dip in as he has time. (no doubt when he sees a target to aim for, he'll be more encouraged to finish them all :) ) Obviously it wouldn't be released until complete, but - if an empty translation is visible, people might contribute more than if they had to commit themselves, so as a tool to assist translation - it's can only help.
Re: Translation help
On Tue, Nov 16, 2010 at 8:34 AM, Bolstridge, Andrew andy.bolstri...@intergraph.com wrote: -Original Message- From: hy...@hyrumwright.org [mailto:hy...@hyrumwright.org] On Behalf Of Hyrum K. Wright Sent: 15 November 2010 18:17 To: Subversion Development Subject: Translation help To any current and/or interested translators: In an effort to make translation of Subversion easier, and more complete, I've installed an instance of Pootle, a web-based translation tool. You can access it here: http://translate.hyrumwright.org/projects/svn/ -Hyrum Nice find, we're thinking of investigating it to see if it would help our internal translation efforts! My colleague Kim might help with a Danish translation, but he is busy so wouldn't be able to commit fully to it - so, would it make sense to put a translation project for Danish on that site so he could dip in as he has time. (no doubt when he sees a target to aim for, he'll be more encouraged to finish them all :) ) That would be great. Kim actually contacted me privately (perhaps just a Reply instead of Reply-All), and I've encouraged him to contact this list to state his intentions if he wants to contribute to the Danish translation. There are *so* many languages, that it seems overkill to list them all, without knowing someone is going to pick up the translation. By having folks mail this list, it not only gets me to add it to the translation page, but also let's others in the community know somebody is working on it. My sense is that people who are contributing meaningful translations, even if only through the Pootle site, would be made committers, following the normal process. That's something for the PMC to discuss, however. Obviously it wouldn't be released until complete, but - if an empty translation is visible, people might contribute more than if they had to commit themselves, so as a tool to assist translation - it's can only help. Actually, we've got several translations which are far from complete, but which still ship. There's probably some minimal threshold translations should meet, but I've got to think it's *very* low. :) -Hyrum
Re: A new 1.7 switch feature?
On 11/16/2010 07:43 AM, Philip Martin wrote: Is this something that we should be supporting? Perhaps we should get rid of the externals code and use this instead? Yes, it appears to work for files. Eek. The file externals feature came about because it just so happened that we supported switches of schedule-add files. I really, *really* don't want us making those kinds of feature decisions in the future on the basis of, Well, gosh, it sorta seems to work. Let's try to be more intentional about such things, shall we? -1, but let's revisit the idea in some post-1.7 release! -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Distributed Development On Demand signature.asc Description: OpenPGP digital signature
scan_deletion - why?
I'm auditing the uses of scan_deletion() and its semi-public wrapper svn_wc__db_scan_deletion(): what do its callers really want? My goals: to be able to understand the callers, and then adapt them to op-depth semantics and also simplify them. It seems to me there's far too much obfuscation going on in these callers at present, with lots of near-but-not-quite-duplication. Here are all the uses and what I can understand about them: 1. adm_crawler.c:find_base_rev() - work_del_abspath This code path is unused in a test suite run. 2. entries.c:get_base_info_for_deleted() (first occurrence) - work_del_abspath Use of result: read_info(dirname(work_del_abspath))+scan_add - repo+relpath Ultimate need: Copyfrom repo+relpath of the deleted node. (The repo+relpath that this path belonged to before it was deleted; if this deletion is inside a move/copy, then the repo location within the copy source.) 3. entries.c:get_base_info_for_deleted() (second occurrence) - base_replaced, work_del_abspath Use of result: base_replaced, read_info(dirname(work_del_abspath))+scan_add - status Ultimate need: Status indications for constructing an entry_t. 4. node.c:svn_wc__node_get_working_rev_info() - base_del_abspath, work_del_abspath This function is only used for back-compat in status reporting. 5. node.c:svn_wc__node_get_commit_base_rev() - work_del_abspath Use of result: read_info(dirname(work_del_abspath))+scan_add - original_rev assert(status is some kind of 'added') Ultimate need: The commit base rev of the deleted node, which probably really means the repository revision of the parent dir of the deletion root. See doc string - should go away. 6. node.c:svn_wc__internal_node_get_schedule() - work_del_abspath Use of result: work_del_abspath == NULL? Ultimate need: To know whether this deletion is inside a copy/move. 7. wc_db.c:get_info_for_copy() - work_del_relpath Use of result: scan_add(dirname(work_del_relpath)) - original_repos_*, op_root Ultimate aim: Copyfrom repos+relpath+rev of the deleted node. ### Relpath of this node, or of root of the copy? 8. wc_db.c:svn_wc__db_global_relocate() - work_del_relpath Use of result: dirname(work_del_relpath) Ultimate aim: Repos+relpath and local path of the parent of the root of the deletion. 9. db-test.c:test_scan_deletion() Several calls, each checking all the output parameters. So what to do with this? Work out what semantics the callers really want, and provide them through one or more APIs. In each case, return the wanted data in a single call instead of providing a path. Then we'll be in a position where we can optimize the queries inside each such function if we need to. 1. Seems unused, so ignore for now. I'm not confident that it can't be triggered. I hope this whole private function can be removed and some (semi-public) API used instead. 2, 5, 7, 8. These are all similar and want to know the repos location of where the deleted node would have been. Need to check carefully what relpath these want: the relpath of the given path, or of the deletion root, or of the parent of the deletion root. Also the revnum - should it be the revnum that the node was at before it was deleted, or the revnum that its parent is at? They can differ in a mixed-rev base or in a copy of a mixed-rev base. 3. Wants status of parent of deletion root. 4. The function for back-compatibility in status reporting. The old, deprecated version of the public status API should retrieve the back-compat fields natively, rather than having the client make a separate call. The newer, revved status API can be non-compatible and avoid that overhead. 6. Is this deletion inside a copy/move? This usage is not a problem and can continue to use scan_deletion or one of the functions that may replace it. 9. Tests: amend as appropriate. The moved_to_abspath output is never used. Ditch it? The base_replaced output is only used in case 3. Ditch it from the main API and use something else in this case? The base_del_abspath output is only used in case 4. Ditch it from the main API and use something else in this case? - Julian
Re: [PATCH] Bug in svn_fs_paths_changed2() Python bindings?
On 11/15/2010 03:05 PM, Alexey Neyman wrote: Hi all, On Wednesday, August 11, 2010 01:09:50 pm C. Michael Pilato wrote: On 08/11/2010 03:10 PM, C. Michael Pilato wrote: On 08/10/2010 09:22 PM, Alexey Neyman wrote: Okay, try again: [[[ Fix the type of structures returned in bindings from svn_fs_paths_changed2(). * subversion/include/svn_fs.h (svn_fs_paths_changed2): Rename the argument from changed_paths_p to changed_paths_p2, so that it's different from argument to svn_fs_paths_changed(). Minor nit -- I think 'changed_paths2_p' would be a better name. To me, a number at the very end of a parameter name says differentiator (as in 'strcmp(str1, str2)') whereas having that '2' closer to the 'changed_paths' name says version iterator. But like I said, it's a minor nit. Otherwise, +1 on the patch. Committed with the aforementioned tweaks in r984565. Thanks, Alexey. Could this patch be picked up in 1.6.14? Regards, Alexey. I've made the proposal. Now, we just need votes. -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Distributed Development On Demand signature.asc Description: OpenPGP digital signature
Re: [PATCH] Fix Perl bindings for svn_auth_get_platform_specific_client_providers
Committed to trunk in r1035745. On Mon, Nov 15, 2010 at 4:24 PM, Gavin Beau Baumanis gav...@thespidernet.com wrote: Ping. This patch submission has received no comments. Gavin Beau Baumanis E: gav...@thespidernet.com On 02/11/2010, at 1:42 AM, Matthijs Kooijman wrote: Hi folks, this is a resubmit of a patch that got lost in the list earlier. The patch is a trivial patch, which adds perl bindings for the apr_array_header_t **providers type, which fixes the svn_auth_get_platform_specific_client_providers function. The patch also includes a basic test case. Gr. Matthijs swig-provider-array.patch
Re: [PATCH] Use svn_fs_fs__id_unparse() to construct the noderev cache key
Since Daniel is a committer, I suspect he will track this change
(relieving you of the burden of doing so).
-Hyrum
On Mon, Nov 15, 2010 at 4:22 PM, Gavin Beau Baumanis
gav...@thespidernet.com wrote:
Ping. This has received no further comments.
Gavin Beau Baumanis
E: gav...@thespidernet.com
On 31/10/2010, at 12:42 PM, Daniel Shahaf wrote:
Is there a reason not to apply this let's not reinvent the wheel patch?
[[[
Index: subversion/libsvn_fs_fs/fs_fs.c
===
--- subversion/libsvn_fs_fs/fs_fs.c (revision 1029231)
+++ subversion/libsvn_fs_fs/fs_fs.c (working copy)
@@ -2205,15 +2205,14 @@ read_rep_offsets(representation_t **rep_p,
return SVN_NO_ERROR;
}
-/* Combine the revision and offset of the ID to a string that will
- * be used as a cache key. Allocations will be made from POOL.
+/* Return a string that uniquely identifies the noderev with the
+ * given ID, for use as a cache key.
*/
static const char *
get_noderev_cache_key(const svn_fs_id_t *id, apr_pool_t *pool)
{
- return svn_fs_fs__combine_two_numbers(svn_fs_fs__id_rev(id),
- svn_fs_fs__id_offset(id),
- pool);
+ const svn_string_t *id_unparsed = svn_fs_fs__id_unparse(id, pool);
+ return id_unparsed-data;
}
/* Look up the NODEREV_P for ID in FS' node revsion cache. If noderev
]]]
(It does not resolve my test failures.)
Daniel
Re: [PATCH] Fix Perl bindings for svn_auth_get_platform_specific_client_providers
Hi Hyrum, Committed to trunk in r1035745. Awesome, thanks! Now it's time to bugger the git maintainers again for the other end of this patch :-) Gr. Matthijs signature.asc Description: Digital signature
Re: [PATCH] Fix Perl bindings for svn_auth_get_platform_specific_client_providers
I guess I also should have asked if this something which should go into the 1.6.x line (I imagine so). -Hyrum On Tue, Nov 16, 2010 at 1:02 PM, Matthijs Kooijman matth...@stdin.nl wrote: Hi Hyrum, Committed to trunk in r1035745. Awesome, thanks! Now it's time to bugger the git maintainers again for the other end of this patch :-) Gr. Matthijs -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkzi1UwACgkQz0nQ5oovr7zwngCg1trovvA+Gwhyx/m1kiI0MXUL VeIAoLeUmKq+yxwgNEbma0Ix1ouknmt/ =ksCG -END PGP SIGNATURE-
Re: [PATCH] Fix Perl bindings for svn_auth_get_platform_specific_client_providers
Hi Hyrum, I guess I also should have asked if this something which should go into the 1.6.x line (I imagine so). The sooner the better, since that would make it more feasible to fix up git to actually use this. Gr. Matthijs signature.asc Description: Digital signature
Re: svn commit: r1035773 - in /subversion/trunk/subversion/bindings/javahl: native/ src/org/apache/subversion/javahl/ src/org/apache/subversion/javahl/type/
On 11/16/10 12:06 PM, hwri...@apache.org wrote: Author: hwright Date: Tue Nov 16 20:06:56 2010 New Revision: 1035773 URL: http://svn.apache.org/viewvc?rev=1035773view=rev Log: JavaHL: Move the Tristate class into the type package. Hyrum, Using type as a package name will cause compile failures if the bindingds are used in a Scala program as type is a reserved word, so having it appear in an import statement will cause problems. I suggest renaming type to to types so it's not a keyword in Scala. Thanks, Blair
Re: svn commit: r1035773 - in /subversion/trunk/subversion/bindings/javahl: native/ src/org/apache/subversion/javahl/ src/org/apache/subversion/javahl/type/
On Tue, Nov 16, 2010 at 2:19 PM, Blair Zajac bl...@orcaware.com wrote: On 11/16/10 12:06 PM, hwri...@apache.org wrote: Author: hwright Date: Tue Nov 16 20:06:56 2010 New Revision: 1035773 URL: http://svn.apache.org/viewvc?rev=1035773view=rev Log: JavaHL: Move the Tristate class into the type package. Hyrum, Using type as a package name will cause compile failures if the bindingds are used in a Scala program as type is a reserved word, so having it appear in an import statement will cause problems. I suggest renaming type to to types so it's not a keyword in Scala. Good suggestion. I'll effect this change RSN. -Hyrum
Windows svnsync test suite failures and a clue
As some of you know I've recently had some strange failures with the svnsync tests on both trunk and 1.6.x. All the tests started failing during setup when the stdout of svnsync init was lost, e.g.: [[[ C:\SVN\src-branch-1.6.xrun.python.test.DEBUG.bat svnsync 1 -v C:\SVN\src-branch-1.6.xset TESTNAME=svnsync C:\SVN\src-branch-1.6.xset CONFIG=Debug C:\SVN\src-branch-1.6.xif not exist Debug\subversion\tests\cmdline mkdir Debug\subversion\tests\cmdline C:\SVN\src-branch-1.6.xpushd Debug\subversion\tests\cmdline C:\SVN\src-branch-1.6.x\Debug\subversion\tests\cmdlinepython C:\SVN\src-branch-1.6.x\\subversion\tests\cmdline\svnsync_tests.py 1 -v CMD: svnadmin.exe create svn-test-work\local_tmp\repos --bdb-txn-nosync TIME = 0.049000 CMD: svn.exe import -m Log message for revision 1. svn-test-work\local_tmp\greekfiles file:///C%3A/SVN/src-branch-1.6.x/Debug/subversion/tests/cmdline/svn- test-work/local_tmp/repos --config-dir C:\SVN\src-branch-1.6.x\Debug\subversion\tests\cmdline\svn-test-work\local_tmp\config --password rayjandom --no-auth-c ache --username jrandom TIME = 0.158000 Adding svn-test-work\local_tmp\greekfiles\A Adding svn-test-work\local_tmp\greekfiles\A\B Adding svn-test-work\local_tmp\greekfiles\A\B\lambda Adding svn-test-work\local_tmp\greekfiles\A\B\E Adding svn-test-work\local_tmp\greekfiles\A\B\E\alpha Adding svn-test-work\local_tmp\greekfiles\A\B\E\beta Adding svn-test-work\local_tmp\greekfiles\A\B\F Adding svn-test-work\local_tmp\greekfiles\A\mu Adding svn-test-work\local_tmp\greekfiles\A\C Adding svn-test-work\local_tmp\greekfiles\A\D Adding svn-test-work\local_tmp\greekfiles\A\D\gamma Adding svn-test-work\local_tmp\greekfiles\A\D\G Adding svn-test-work\local_tmp\greekfiles\A\D\G\pi Adding svn-test-work\local_tmp\greekfiles\A\D\G\rho Adding svn-test-work\local_tmp\greekfiles\A\D\G\tau Adding svn-test-work\local_tmp\greekfiles\A\D\H Adding svn-test-work\local_tmp\greekfiles\A\D\H\chi Adding svn-test-work\local_tmp\greekfiles\A\D\H\omega Adding svn-test-work\local_tmp\greekfiles\A\D\H\psi Adding svn-test-work\local_tmp\greekfiles\iota Committed revision 1. CMD: svnadmin.exe create svn-test-work\repositories\svnsync_tests-1 --bdb-txn-nosync TIME = 0.096000 CMD: svnadmin.exe load --force-uuid --quiet svn-test-work\repositories\svnsync_tests-1 TIME = 0.168000 CMD: svnadmin.exe create svn-test-work\repositories\svnsync_tests-1-1 --bdb-txn-nosync TIME = 0.134000 CMD: svnlook.exe uuid svn-test-work\repositories\svnsync_tests-1 TIME = 0.026000 6ad9f820-0205-0410-94a2-c8cf366bb2b3 CMD: svnadmin.exe setuuid svn-test-work\repositories\svnsync_tests-1-1 6ad9f820-0205-0410-94a2-c8cf366bb2b3 TIME = 0.048000 CMD: svnsync.exe initialize file:///C%3A/SVN/src-branch-1.6.x/Debug/subversion/tests/cmdline/svn-test-work/repositories/svnsync_tests-1-1 file:///C%3A/SVN/sr c-branch-1.6.x/Debug/subversion/tests/cmdline/svn-test-work/repositories/svnsync_tests-1 --username jrandom --password rayjandom --config-dir C:\SVN\src-branc h-1.6.x\Debug\subversion\tests\cmdline\svn-test-work\local_tmp\config TIME = 0.314000 EXCEPTION: SVNUnexpectedStdout: [] Traceback (most recent call last): File C:\SVN\src-branch-1.6.x\subversion\tests\cmdline\svntest\main.py, line 1226, in run rc = self.pred.run(**kw) File C:\SVN\src-branch-1.6.x\subversion\tests\cmdline\svntest\testcase.py, line 121, in run return self.func(sandbox) File C:\SVN\src-branch-1.6.x\\subversion\tests\cmdline\svnsync_tests.py, line 193, in copy_and_modify run_test(sbox, copy-and-modify.dump) File C:\SVN\src-branch-1.6.x\\subversion\tests\cmdline\svnsync_tests.py, line 157, in run_test run_init(dest_sbox.repo_url, repo_url) File C:\SVN\src-branch-1.6.x\\subversion\tests\cmdline\svnsync_tests.py, line 100, in run_init raise SVNUnexpectedStdout(output) SVNUnexpectedStdout: [] FAIL: svnsync_tests.py 1: copy and modify ]]] When I first saw these failures on trunk a few weeks ago I didn't think much of them, just figured they were due to some ongoing work. Then the 1.6.x svnsync tests started failing. I had tested 1.6.13 recently without problem, so I built the 1.6.13 tag and sure enough it now failed. My first thought was a recently changed dependency, but I've been using this setup for several months: PLATFORM: - MS Windows 7 Home Premium 6.1.7600 Build 7600 Intel Core i7 M 620 2.67GHz 4 GB RAM Microsoft Visual Studio 2008 Version 9.0.30729.1 SP DEPENDENCIES: - APR: 1.4.2 APR-UTIL: 1.3.9 Neon: 0.29.3 zlib: 1.2.3 OpenSSL: 0.9.8m Apache: 2.2.15 BDB: 4.8.30 sqlite: 3.7.2 Python: ActivePython 2.6.5.14 Perl: 5.10.1 Ruby: ruby 1.8.7 java: 1.6.0_21 junit: 4.8.2 swig: 1.3.40 serf: 0.3.0 The only thing that I can think of that *has* changed is that I regularly run Windows Update. After trying to figure what was wrong and hitting a dead end, I restored my
Re: scan_deletion - why?
I'm not sure that I understand the goal here. Is there a problem that is trying to be solved? If not, then I'd recommend just marking this down as an item to review in 1.8. Cheers, -g On Tue, Nov 16, 2010 at 12:51, Julian Foad julian.f...@wandisco.com wrote: I'm auditing the uses of scan_deletion() and its semi-public wrapper svn_wc__db_scan_deletion(): what do its callers really want? My goals: to be able to understand the callers, and then adapt them to op-depth semantics and also simplify them. It seems to me there's far too much obfuscation going on in these callers at present, with lots of near-but-not-quite-duplication. Here are all the uses and what I can understand about them: 1. adm_crawler.c:find_base_rev() - work_del_abspath This code path is unused in a test suite run. 2. entries.c:get_base_info_for_deleted() (first occurrence) - work_del_abspath Use of result: read_info(dirname(work_del_abspath))+scan_add - repo+relpath Ultimate need: Copyfrom repo+relpath of the deleted node. (The repo+relpath that this path belonged to before it was deleted; if this deletion is inside a move/copy, then the repo location within the copy source.) 3. entries.c:get_base_info_for_deleted() (second occurrence) - base_replaced, work_del_abspath Use of result: base_replaced, read_info(dirname(work_del_abspath))+scan_add - status Ultimate need: Status indications for constructing an entry_t. 4. node.c:svn_wc__node_get_working_rev_info() - base_del_abspath, work_del_abspath This function is only used for back-compat in status reporting. 5. node.c:svn_wc__node_get_commit_base_rev() - work_del_abspath Use of result: read_info(dirname(work_del_abspath))+scan_add - original_rev assert(status is some kind of 'added') Ultimate need: The commit base rev of the deleted node, which probably really means the repository revision of the parent dir of the deletion root. See doc string - should go away. 6. node.c:svn_wc__internal_node_get_schedule() - work_del_abspath Use of result: work_del_abspath == NULL? Ultimate need: To know whether this deletion is inside a copy/move. 7. wc_db.c:get_info_for_copy() - work_del_relpath Use of result: scan_add(dirname(work_del_relpath)) - original_repos_*, op_root Ultimate aim: Copyfrom repos+relpath+rev of the deleted node. ### Relpath of this node, or of root of the copy? 8. wc_db.c:svn_wc__db_global_relocate() - work_del_relpath Use of result: dirname(work_del_relpath) Ultimate aim: Repos+relpath and local path of the parent of the root of the deletion. 9. db-test.c:test_scan_deletion() Several calls, each checking all the output parameters. So what to do with this? Work out what semantics the callers really want, and provide them through one or more APIs. In each case, return the wanted data in a single call instead of providing a path. Then we'll be in a position where we can optimize the queries inside each such function if we need to. 1. Seems unused, so ignore for now. I'm not confident that it can't be triggered. I hope this whole private function can be removed and some (semi-public) API used instead. 2, 5, 7, 8. These are all similar and want to know the repos location of where the deleted node would have been. Need to check carefully what relpath these want: the relpath of the given path, or of the deletion root, or of the parent of the deletion root. Also the revnum - should it be the revnum that the node was at before it was deleted, or the revnum that its parent is at? They can differ in a mixed-rev base or in a copy of a mixed-rev base. 3. Wants status of parent of deletion root. 4. The function for back-compatibility in status reporting. The old, deprecated version of the public status API should retrieve the back-compat fields natively, rather than having the client make a separate call. The newer, revved status API can be non-compatible and avoid that overhead. 6. Is this deletion inside a copy/move? This usage is not a problem and can continue to use scan_deletion or one of the functions that may replace it. 9. Tests: amend as appropriate. The moved_to_abspath output is never used. Ditch it? The base_replaced output is only used in case 3. Ditch it from the main API and use something else in this case? The base_del_abspath output is only used in case 4. Ditch it from the main API and use something else in this case? - Julian
Re: [PATCH] Use svn_fs_fs__id_unparse() to construct the noderev cache key
Hyrum K. Wright wrote on Tue, Nov 16, 2010 at 13:02:04 -0600:
Since Daniel is a committer, I suspect he will track this change
(relieving you of the burden of doing so).
That's correct.
-Hyrum
On Mon, Nov 15, 2010 at 4:22 PM, Gavin Beau Baumanis
gav...@thespidernet.com wrote:
Ping. This has received no further comments.
Gavin Beau Baumanis
E: gav...@thespidernet.com
On 31/10/2010, at 12:42 PM, Daniel Shahaf wrote:
Is there a reason not to apply this let's not reinvent the wheel patch?
[[[
Index: subversion/libsvn_fs_fs/fs_fs.c
===
--- subversion/libsvn_fs_fs/fs_fs.c (revision 1029231)
+++ subversion/libsvn_fs_fs/fs_fs.c (working copy)
@@ -2205,15 +2205,14 @@ read_rep_offsets(representation_t **rep_p,
return SVN_NO_ERROR;
}
-/* Combine the revision and offset of the ID to a string that will
- * be used as a cache key. Allocations will be made from POOL.
+/* Return a string that uniquely identifies the noderev with the
+ * given ID, for use as a cache key.
*/
static const char *
get_noderev_cache_key(const svn_fs_id_t *id, apr_pool_t *pool)
{
- return svn_fs_fs__combine_two_numbers(svn_fs_fs__id_rev(id),
- svn_fs_fs__id_offset(id),
- pool);
+ const svn_string_t *id_unparsed = svn_fs_fs__id_unparse(id, pool);
+ return id_unparsed-data;
}
/* Look up the NODEREV_P for ID in FS' node revsion cache. If noderev
]]]
(It does not resolve my test failures.)
Daniel
Re: [PATCH] Use svn_fs_fs__id_unparse() to construct the noderev cache key
On 17.11.2010 00:11, Daniel Shahaf wrote:
Hyrum K. Wright wrote on Tue, Nov 16, 2010 at 13:02:04 -0600:
Since Daniel is a committer, I suspect he will track this change
(relieving you of the burden of doing so).
That's correct.
-Hyrum
I'm not decided about that patch, yet. id_unparse is
relatively slow and I basically need to do some measurement
whether that is relevant (i.e. called frequently) or not.
-- Stefan^2.
On Mon, Nov 15, 2010 at 4:22 PM, Gavin Beau Baumanis
gav...@thespidernet.com wrote:
Ping. This has received no further comments.
Gavin Beau Baumanis
E: gav...@thespidernet.com
On 31/10/2010, at 12:42 PM, Daniel Shahaf wrote:
Is there a reason not to apply this let's not reinvent the wheel patch?
[[[
Index: subversion/libsvn_fs_fs/fs_fs.c
===
--- subversion/libsvn_fs_fs/fs_fs.c (revision 1029231)
+++ subversion/libsvn_fs_fs/fs_fs.c (working copy)
@@ -2205,15 +2205,14 @@ read_rep_offsets(representation_t **rep_p,
return SVN_NO_ERROR;
}
-/* Combine the revision and offset of the ID to a string that will
- * be used as a cache key. Allocations will be made from POOL.
+/* Return a string that uniquely identifies the noderev with the
+ * given ID, for use as a cache key.
*/
static const char *
get_noderev_cache_key(const svn_fs_id_t *id, apr_pool_t *pool)
{
- return svn_fs_fs__combine_two_numbers(svn_fs_fs__id_rev(id),
-svn_fs_fs__id_offset(id),
-pool);
+ const svn_string_t *id_unparsed = svn_fs_fs__id_unparse(id, pool);
+ return id_unparsed-data;
}
/* Look up the NODEREV_P for ID in FS' node revsion cache. If noderev
]]]
(It does not resolve my test failures.)
Daniel
Re: Issue triage: issues 3429 and 3474
On Mon, Nov 8, 2010 at 1:02 PM, Philip Martin philip.mar...@wandisco.com wrote: Johan Corveleyn jcor...@gmail.com writes: Or, maybe the best approach: I could add a regression test for these issues, so we can all be sure that they are fixed (and remain fixed), after which they can be marked as fixed. Yes, please. Are there any existing XFAIL tests that apply? They sometimes don't XPASS automatically when the bug is fixed because the test expectation is wrong. Doh, it seems that issue #3474 already has a test, which PASSes (added by Bert, which he mentioned in a comment in the issue): PASS: copy_tests.py 81: copy of new dir with copied file keeps history This is exactly what issue #3474 is about. Bert added the test as XFAIL in r938071, and it was marked PASS by you, Philip, in r955334. So, I guess this wraps up that issue: can someone mark it as resolved? There was a slight confusion when I read the test code, because a comment still talks about the tests as Currently this fails because The following patch removes that obsolete comment: [[[ Index: subversion/tests/cmdline/copy_tests.py === --- subversion/tests/cmdline/copy_tests.py (revision 1035851) +++ subversion/tests/cmdline/copy_tests.py (working copy) @@ -4358,8 +4358,6 @@ def copy_added_dir_with_copy(sbox): 'NewDir2/mu': Item(status='A ', copied='+', wc_rev='-'), }) - # Currently this fails because NewDir2/mu loses its history in the copy - # from NewDir to NewDir2 svntest.actions.run_and_verify_status(wc_dir, expected_status) ]]] For issue #3429, I'll try to write a regression test myself, and post a patch for it in a new thread. Cheers, -- Johan
[PATCH] copy_tests.py - expand move_file_back_and_forth, to verify issue #3429
The attached patch expands the test move_file_back_and_forth
(copy_tests.py 45) as a regression test for issue#3429.
[[[
Expand move_file_back_and_forth test to verify issue #3429
(svn mv A B; svn mv B A generates replace without history).
* subversion/tests/cmdline/copy_tests.py
(move_file_back_and_forth): Check expected status before commit.
]]]
Cheers,
--
Johan
Index: subversion/tests/cmdline/copy_tests.py
===
--- subversion/tests/cmdline/copy_tests.py (revision 1035851)
+++ subversion/tests/cmdline/copy_tests.py (working copy)
@@ -2428,17 +2428,27 @@ def move_file_back_and_forth(sbox):
svntest.actions.run_and_verify_svn(None, None, [], 'mv',
rho_move_path, rho_path)
+ # Create expected status tree before commit
+ expected_status = svntest.actions.get_virginal_state(wc_dir, 1)
+ expected_status.add({
+'A/D/G/rho' : Item(status='R ', copied='+', wc_rev='-'),
+})
+
+ # Test status before commit
+ svntest.actions.run_and_verify_status(wc_dir, expected_status)
+
# Created expected output tree for 'svn ci':
expected_output = svntest.wc.State(wc_dir, {
'A/D/G/rho' : Item(verb='Replacing'),
})
- # Create expected status tree
+ # Create expected status tree after commit
expected_status = svntest.actions.get_virginal_state(wc_dir, 1)
expected_status.add({
'A/D/G/rho' : Item(status=' ', wc_rev=2),
})
+ # Test commit output and status
svntest.actions.run_and_verify_commit(wc_dir,
expected_output,
expected_status,
Re: [PATCH] copy_tests.py - expand move_file_back_and_forth, to verify issue #3429
On Wed, Nov 17, 2010 at 2:14 AM, Johan Corveleyn jcor...@gmail.com wrote:
The attached patch expands the test move_file_back_and_forth
(copy_tests.py 45) as a regression test for issue#3429.
[[[
Expand move_file_back_and_forth test to verify issue #3429
(svn mv A B; svn mv B A generates replace without history).
* subversion/tests/cmdline/copy_tests.py
(move_file_back_and_forth): Check expected status before commit.
]]]
I just realized that I can add a similar check to
move_dir_back_and_forth. Here is a second patch that expands both
tests.
(note: can the if svntest.main.wc_is_singledb(wc_dir) be dropped
from move_dir_back_and_forth?)
Log message:
[[[
Expand move_file_back_and_forth and move_dir_back_and_forth tests to verify
issue #3429 (svn mv A B; svn mv B A generates replace without history).
* subversion/tests/cmdline/copy_tests.py
(move_file_back_and_forth): Check expected status before commit.
(move_dir_back_and_forth): Check expected status after executing the moves.
]]]
Cheers,
--
Johan
Index: subversion/tests/cmdline/copy_tests.py
===
--- subversion/tests/cmdline/copy_tests.py (revision 1035851)
+++ subversion/tests/cmdline/copy_tests.py (working copy)
@@ -2428,17 +2428,27 @@ def move_file_back_and_forth(sbox):
svntest.actions.run_and_verify_svn(None, None, [], 'mv',
rho_move_path, rho_path)
+ # Create expected status tree before commit
+ expected_status = svntest.actions.get_virginal_state(wc_dir, 1)
+ expected_status.add({
+'A/D/G/rho' : Item(status='R ', copied='+', wc_rev='-'),
+})
+
+ # Test status before commit
+ svntest.actions.run_and_verify_status(wc_dir, expected_status)
+
# Created expected output tree for 'svn ci':
expected_output = svntest.wc.State(wc_dir, {
'A/D/G/rho' : Item(verb='Replacing'),
})
- # Create expected status tree
+ # Create expected status tree after commit
expected_status = svntest.actions.get_virginal_state(wc_dir, 1)
expected_status.add({
'A/D/G/rho' : Item(status=' ', wc_rev=2),
})
+ # Test commit output and status
svntest.actions.run_and_verify_commit(wc_dir,
expected_output,
expected_status,
@@ -2474,6 +2484,23 @@ def move_dir_back_and_forth(sbox):
svntest.actions.run_and_verify_svn(None, None, expected_err,
'mv', D_move_path, D_path)
+ if svntest.main.wc_is_singledb(wc_dir):
+# Verify if status indicates a replace with history
+expected_status = svntest.actions.get_virginal_state(wc_dir, 1)
+expected_status.add({
+ 'A/D' : Item(status='R ', copied='+', wc_rev='-'),
+ 'A/D/G' : Item(status=' ', copied='+', wc_rev='-'),
+ 'A/D/G/pi' : Item(status=' ', copied='+', wc_rev='-'),
+ 'A/D/G/rho' : Item(status=' ', copied='+', wc_rev='-'),
+ 'A/D/G/tau' : Item(status=' ', copied='+', wc_rev='-'),
+ 'A/D/gamma' : Item(status=' ', copied='+', wc_rev='-'),
+ 'A/D/H' : Item(status=' ', copied='+', wc_rev='-'),
+ 'A/D/H/chi' : Item(status=' ', copied='+', wc_rev='-'),
+ 'A/D/H/omega' : Item(status=' ', copied='+', wc_rev='-'),
+ 'A/D/H/psi' : Item(status=' ', copied='+', wc_rev='-'),
+ })
+svntest.actions.run_and_verify_status(wc_dir, expected_status)
+
def copy_move_added_paths(sbox):
copy and move added paths without commits
Re: svn commit: r1035869 [1/19] - in /subversion/branches/performance: ./ build/ build/generator/ build/generator/templates/ build/win32/ subversion/bindings/javahl/native/ subversion/bindings/javahl/
On Wed, Nov 17, 2010 at 12:09:55AM -, stef...@apache.org wrote: Author: stefan2 Date: Wed Nov 17 00:09:50 2010 New Revision: 1035869 URL: http://svn.apache.org/viewvc?rev=1035869view=rev Log: On the performance branch: Bring up-to-date with trunk. [lots of tree conflicts due to moved files were to resolve] Just out of curiousity: Can you describe what kinds of conflicts you were seeing? Were the tree conflicts within the build/generator directory? Or elsewhere, too? Tree conflicts should only happen if you also deleted/moved/edited the correspponding files (or directories) on the performance branch.
