Re: svn commit: r1657026 - in /subversion/trunk/subversion: bindings/javahl/native/ bindings/javahl/src/org/apache/subversion/javahl/ include/ libsvn_client/ libsvn_wc/ svn/ tests/libsvn_wc/
On 04.02.2015 09:36, rhuij...@apache.org wrote: > Author: rhuijben > Date: Wed Feb 4 08:36:20 2015 > New Revision: 1657026 > > URL: http://svn.apache.org/r1657026 > Log: > As we are revving svn_client_revert() for 1.9 anyway, now is the time to > give it a 'metadata_only' flag, like we have on copy and move. I understand the case for a metadata-only copy and/or move. What's the use case for doing a metadata-only revert? -- Brane
Re: svn commit: r1656616 - in /subversion/branches/reuse-ra-session: BRANCH-README subversion/libsvn_client/client.h subversion/libsvn_client/ra_cache.c
On 04.02.2015 03:22, Greg Stein wrote: > On Mon, Feb 2, 2015 at 7:52 PM, wrote: >> ... >> +++ subversion/branches/reuse-ra-session/BRANCH-README Tue Feb 3 01:52:26 >> 2015 >> @@ -8,12 +8,19 @@ all changes made in the branch. >> >> STATUS >> == >> -+ Initial implementation >> -- Do not call svn_ra_* methods in find_session_by_url() because callback >> - table may be destroyed at that time. >> + >> +done: >> +- Initial implementation. >> +- Separate active and inactive session lists. >> + >> +todo: >> +- Fix timeout in davautocheck tests at log_tests.py::log_diff_moved. >> +- Limit the number of unused open sessions. >> +- Run performance comparisons between trunk and branch to prove that >> + the RA session cache does in fact speed things up. >> > This is the part that I wonder about. If we had 1000 sessions, then I > *might* start to believe a separation would be interesting. > > A cache of sessions: sure; that's why we already had a cache. > > But to split that apart and keep multiple lists? Did you have an indicator > somewhere that this split could help? That "get me a connected RA session" > was somehow noticeably slow, relative to a simple iteration sessions? The important reason is that with this split it's much easier to manage the cached idle sessions than it was before the change. Before, all the sessions were stored in an unordered hash table, and the difference between 'idle' and 'active' was in a few bits of data in the cache entry struct. Now, the idle sessions are stored in a doubly-linked list, which is ordered. This will make it easier in future to limit the number of cached idle sessions and to remove the least-recently-used ones from the cache. It also ensures that when we want to reuse a session, we'll always pick the one that was released most recently, which reduces the chance that the session might have become invalid (connection timed out, Kerberos token invalidated, etc.) while it's been idle. And yes, I do expect that iterating through a shorter list will save nanoseconds. :) -- Brane
RE: svn commit: r1657026 - in /subversion/trunk/subversion: bindings/javahl/native/ bindings/javahl/src/org/apache/subversion/javahl/ include/ libsvn_client/ libsvn_wc/ svn/ tests/libsvn_wc/
> -Original Message- > From: Branko Čibej [mailto:br...@wandisco.com] > Sent: woensdag 4 februari 2015 10:23 > To: dev@subversion.apache.org > Subject: Re: svn commit: r1657026 - in /subversion/trunk/subversion: > bindings/javahl/native/ bindings/javahl/src/org/apache/subversion/javahl/ > include/ libsvn_client/ libsvn_wc/ svn/ tests/libsvn_wc/ > > On 04.02.2015 09:36, rhuij...@apache.org wrote: > > Author: rhuijben > > Date: Wed Feb 4 08:36:20 2015 > > New Revision: 1657026 > > > > URL: http://svn.apache.org/r1657026 > > Log: > > As we are revving svn_client_revert() for 1.9 anyway, now is the time to > > give it a 'metadata_only' flag, like we have on copy and move. > > I understand the case for a metadata-only copy and/or move. > What's the use case for doing a metadata-only revert? In my particular case: Users automatically replacing files like .dll's (shared libraries) and .xls document files. The delete is automatically handled and properly recorded as a delete in Subversion. (The --keep-local flag is essentially delete's metadata only, as it allows deleting without error) But then the file is replaced, by some outside process. The current worst case is the NuGet Visual Studio addin, that just tells me that the user does things (who doesn't) and sometimes blocks access. The user goes on with his work and locks the file... (opens excel, starts debugging, whatever) Now the user wants to commit his workspace, but explicitly doesn't want to record the delete + add as a delete, but as a normal file update. To change the in-wc state to a normal update I have to call revert... But that currently requires replacing the in-wc file with the old version. (And moving around the file to keep the copy has all those other nice side effects) This patch allows handling this workflow with a single call to revert, that typically can't fail unless another Subversion client changes the same wc at the same time. TortoiseSVN has a similar workflow, somewhere in its context menus. Bert
Re: svn commit: r1656893 - in /subversion/trunk/subversion: svnsync/sync.c tests/cmdline/svnsync_tests_data/mergeinfo-contains-r0.dump tests/cmdline/svnsync_tests_data/mergeinfo-contains-r0.expected.d
Hi Philip, Thanks for fixing my embarrassing bug. I've just finished fixing this too, and expanding the test, and then found you already committed this last night. We should have used more words to communicate. The fix was easy (not too different from yours) but I spent some time on the tests. As I think I have made a considerably more thorough set of test cases for this issue, I'm taking the liberty of committing that part. r1657182. Apparently we had no test that synced a repository containing merginfo at all. That's another deficiency we could address with the approach of running additional (svnsync in this case) tests at the end of existing tests. I'll look into doing that after reintegrating the 'dump-load-cross-check' branch. - Julian > Author: philip > Date: Tue Feb 3 19:07:09 2015 > New Revision: 1656893 > > URL: http://svn.apache.org/r1656893 > Log: > Fix svnsync r0 filtering to handle svn:mergeinfo where not all > lines contain r0. > > * subversion/svnsync/sync.c > (remove_r0_mergeinfo): Build up new string when r0 not present. > > [In subversion/tests/cmdline/svnsync_tests_data/] > > * mergeinfo-contains-r0.dump: Extend with svn:mergeinfo that has > only some, or no, lines with r0. > > * mergeinfo-contains-r0.expected.dump: Adjust. > > Modified: > subversion/trunk/subversion/svnsync/sync.c > > subversion/trunk/subversion/tests/cmdline/svnsync_tests_data/mergeinfo-contains-r0.dump > > subversion/trunk/subversion/tests/cmdline/svnsync_tests_data/mergeinfo-contains-r0.expected.dump
Re: svn commit: r1656893 - in /subversion/trunk/subversion: svnsync/sync.c tests/cmdline/svnsync_tests_data/mergeinfo-contains-r0.dump tests/cmdline/svnsync_tests_data/mergeinfo-contains-r0.expected.d
I (Julian Foad) wrote: > I've just finished fixing this too, and expanding the test, and then found > you already committed this last night. We should have used more words to > communicate. The fix was easy (not too different from yours) but I spent some > time on the tests. It turns out your fix was not quite right -- see r1657195. Before committing r1657182, I briefly inspected it and thought it looked OK and re-ran my tests on it but I must have failed to re-build. The buildbots caught it. - Julian
Enhancement requests
Can we manage enhancement requests better? Users often ask when they can have a certain feature. For example, I was asked recently (for a customer at work) when diff and patch will support full Subversion tree changes such as copy and rename. That's an issue that I personally think is important and has been mentioned in the tracker for a long time (ahem, 2003). Over the years we've added bits of support in the area (such as git diff format) but it still has no road map, and there isn't a single issue describing it, and there is not even a vague design plan written down for it as far as I can find. The users generally want to know whether the feature is on our roadmap, approximately when we will develop it, and where it is on our priority list -- that is, what other developments are higher priority. Our usual response is that we don't have a priority list, we only put a few key goals on our roadmap, and it will happen when somebody makes it happen. We say we're volunteer-led so there's no way to force anything to be done. But is it good for us to have no priorities about most proposals and not to make any further decisions about the proposed enhancement, just leaving it to possibly happen one day? I think it would be good for us if we were a bit more active in managing things. I think one element needed here is some way in which the user can see what *is* planned. Communication often helps things go well in life generally. For an enhancement that is not planned, we might suppose there would be not much to see, but there should still be something saying: "yes this enhancement is one that we agree we want, and is waiting for developer resources to do it". Or "this proposal has been assessed as not currently of much interest to the community as a whole, but of course this decision can be reviewed if anyone wishes". Would it help if we maintain some sort of priority indicator in the issue tracker or on the web? Should we be going through the issues in the tracker and "triaging" them, deciding how sensible/important/feasible they are and rejecting the weak ones, much more actively than we currently do? I would be willing to do more of that. Should we spend a bit more time jointly exploring some of the main ideas that we're all largely aware of (things we broadly agree we want but haven't dug into), a sort of sketching out of high level design goals, that would not be binding but could then be recorded as projects that are a bit more ready to work on that just an initial idea? Should we spend a bit more effort on our web pages, particularly the "what's in development and what's next" pages? I think that would be useful in encouraging potential helpers to get interested and to contact us. What do others think? - Julian
Re: [vote] pin-externals branch to trunk
On Fri, Jan 30, 2015 at 06:14:02PM +0100, Stefan Kueng wrote: > But can you maybe implement my other request about using an array of > externals to tag so the user can chose which externals to tag and which ones > to just leave as-is? Does this API do the job? http://svn.apache.org/r1657267
RE: svn commit: r1657267 - in /subversion/branches/pin-externals/subversion: include/svn_client.h libsvn_client/copy.c libsvn_client/deprecated.c svn/copy-cmd.c tests/libsvn_client/client-test.c
> -Original Message- > From: s...@apache.org [mailto:s...@apache.org] > Sent: woensdag 4 februari 2015 15:59 > To: comm...@subversion.apache.org > Subject: svn commit: r1657267 - in /subversion/branches/pin- > externals/subversion: include/svn_client.h libsvn_client/copy.c > libsvn_client/deprecated.c svn/copy-cmd.c tests/libsvn_client/client-test.c > > Author: stsp > Date: Wed Feb 4 14:58:59 2015 > New Revision: 1657267 > > URL: http://svn.apache.org/r1657267 > Log: > On the pin-externals branch, allow fine-grained API-level control over which > externals get pinned during a copy. This feature is intended for clients which > allow users to select specific externals for pinning, like TortoiseSVN does. > > Suggested by: steveking > > * subversion/include/svn_client.h > (svn_client_copy7): Add externals_to_pin parameter. Extend docstring. > > * subversion/libsvn_client/copy.c > (make_external_description): New. Factored out from pin_externals_prop(). > (pin_externals_prop): Add externals_to_pin parameter. If set, only pin >externals matching those in externals_to_pin. > (resolve_pinned_externals, do_wc_to_wc_copies_with_write_lock, >do_wc_to_wc_copies, repos_to_repos_copy, wc_to_repos_copy, >repos_to_wc_copy_single, repos_to_wc_copy_locked, repos_to_wc_copy, >try_copy, svn_client_copy7): Add new externals_to_pin parameter > and pass it all the way down to pin_externals_prop(). > (svn_client_move7): Pass NULL for externals_to_pin. > > * subversion/libsvn_client/deprecated.c > (svn_client_copy6): Pass NULL for externals_to_pin. > > * subversion/svn/copy-cmd.c > (svn_cl__copy): Pass NULL for externals_to_pin. > > * subversion/tests/libsvn_client/client-test.c > (test_copy_pin_externals, test_funcs): New test. > > Modified: > subversion/branches/pin-externals/subversion/include/svn_client.h > subversion/branches/pin-externals/subversion/libsvn_client/copy.c > subversion/branches/pin-externals/subversion/libsvn_client/deprecated.c > subversion/branches/pin-externals/subversion/svn/copy-cmd.c > subversion/branches/pin-externals/subversion/tests/libsvn_client/client- > test.c > > Modified: subversion/branches/pin-externals/subversion/include/svn_client.h > URL: http://svn.apache.org/viewvc/subversion/branches/pin- > externals/subversion/include/svn_client.h?rev=1657267&r1=1657266&r2=1657 > 267&view=diff > > == > --- subversion/branches/pin-externals/subversion/include/svn_client.h > (original) > +++ subversion/branches/pin-externals/subversion/include/svn_client.h Wed > Feb 4 14:58:59 2015 > @@ -4493,8 +4493,16 @@ typedef struct svn_client_copy_source_t > * as part of this operation. > * > * If @a pin_externals is set, pin URLs in copied externals definitions > - * to their last-changed revision unless they were already pinned to a > - * particular revision. > + * to their current revision unless they were already pinned to a > + * particular revision. If non-NULL, @a externals_to_pin restricts pinning > + * to a subset of externals. It is a hash table keyed by either a local > + * absolute path or a URL at which an svn:externals property is set. > + * The hash table contains apr_array_header_t* elements as returned > + * by svn_wc_parse_externals_description3(). These arrays contain elements > + * of type svn_wc_external_item2_t*. Externals corresponding to these > + * items will be pinned, other externals will not be pinned. > + * If @a externals_to_pin is @c NULL then all externals are pinned. > + * If @a pin_externals is @c FALSE then @a externals_to_pin is ignored. " absolute path or a URL at which an svn:externals property is set." When should I use URL and when an abspath? Does that depend on which copy operation I use? (repos->wc, wc->wc, repos->repos) Do I need to specify the source or the destination path/url? This already huge chunk of documentation, still leaves out a lot of details I would need to use it. Personally I liked the feature better, before adding this configuration knob, which still doesn't allow per external pinning (only per svn:externals property), and still requires api users to walk all the externals themselves. Bert
Re: svn commit: r1657267 - in /subversion/branches/pin-externals/subversion: include/svn_client.h libsvn_client/copy.c libsvn_client/deprecated.c svn/copy-cmd.c tests/libsvn_client/client-test.c
On Wed, Feb 04, 2015 at 04:30:11PM +0100, Bert Huijben wrote: > > * If @a pin_externals is set, pin URLs in copied externals definitions > > - * to their last-changed revision unless they were already pinned to a > > - * particular revision. > > + * to their current revision unless they were already pinned to a > > + * particular revision. If non-NULL, @a externals_to_pin restricts pinning > > + * to a subset of externals. It is a hash table keyed by either a local > > + * absolute path or a URL at which an svn:externals property is set. > > + * The hash table contains apr_array_header_t* elements as returned > > + * by svn_wc_parse_externals_description3(). These arrays contain elements > > + * of type svn_wc_external_item2_t*. Externals corresponding to these > > + * items will be pinned, other externals will not be pinned. > > + * If @a externals_to_pin is @c NULL then all externals are pinned. > > + * If @a pin_externals is @c FALSE then @a externals_to_pin is ignored. > > " absolute path or a URL at which an svn:externals property is set." > > When should I use URL and when an abspath? > Does that depend on which copy operation I use? (repos->wc, wc->wc, > repos->repos) If the copy source is a URL, then use a URL. If the copy source is a WC, then use an abspath. This is just what is returned from the APIs you can use to recursively list properties. > Do I need to specify the source or the destination path/url? Source/Destination of what? The copy? The external? > This already huge chunk of documentation, still leaves out a lot of details I > would need to use it. Let's try to improve it then. > Personally I liked the feature better, before adding this configuration knob, > which still doesn't allow per external pinning (only per svn:externals > property), and still requires api users to walk all the externals themselves. It does allow for pinning indivual externals. Each item in the array (the hash table's value for a given abspath_or_url) corresponds to one line in an svn:externals property, i.e. the definition of a single external. It is matched by external URL (in unresolved form, i.e. relative external URLs stay relative) and the target path provided in the external definition. Together, these uniquely identify an individual external. Of course, the API user needs to walk externals first and then select a few of them for pinning. I don't see a way around that. How else can we find out which externals the API user wants to pin?
Re: [vote] pin-externals branch to trunk
On 04.02.2015 16:07, Stefan Sperling wrote: On Fri, Jan 30, 2015 at 06:14:02PM +0100, Stefan Kueng wrote: But can you maybe implement my other request about using an array of externals to tag so the user can chose which externals to tag and which ones to just leave as-is? Does this API do the job? http://svn.apache.org/r1657267 Perfect! That's what I needed. Maybe one more improvement: Add a new API to fetch the list of externals which would be pegged if NULL is passed to the svn_client_copy7 API. Suggested name: svn_client_get_externals_for_copy() which returns the hash of all externals. I figure the code to do that is already in place (you have to do that if NULL is passed). And it would make it easier for clients. I can easily do this myself on a working copy, but I'm guessing I can't do it using the client API's as efficiently as a new API could for urls. Stefan -- ___ oo // \\ "De Chelonian Mobile" (_,\/ \_/ \ TortoiseSVN \ \_/_\_/>The coolest interface to (Sub)version control /_/ \_\ http://tortoisesvn.net
Re: svn commit: r1656893 - in /subversion/trunk/subversion: svnsync/sync.c tests/cmdline/svnsync_tests_data/mergeinfo-contains-r0.dump tests/cmdline/svnsync_tests_data/mergeinfo-contains-r0.expected.d
So we're on the third version of the code and third version of the test, for a tiny edge-case feature. Clearly it's fragile. I had a bad feeling about writing it this way in the first place. I have proceeded to implement 'svnsync' cross-checking in the test suite: running every repository produced by a test through 'svnsync' and checking there is no change. This turns up at least one further bug: assertion failure on deleting a mergeinfo property. I'll get to fixing that and committing the extra testing tomorrow. - Julian
Re: [vote] pin-externals branch to trunk
On Wed, Feb 04, 2015 at 06:42:08PM +0100, Stefan Kueng wrote: > Maybe one more improvement: > Add a new API to fetch the list of externals which would be pegged if NULL > is passed to the svn_client_copy7 API. > > Suggested name: svn_client_get_externals_for_copy() > which returns the hash of all externals. > I figure the code to do that is already in place (you have to do that if > NULL is passed). And it would make it easier for clients. > > I can easily do this myself on a working copy, but I'm guessing I can't do > it using the client API's as efficiently as a new API could for urls. A recursive propget on the copy source gives you that list. Plus you'd have to pass the externals you get through svn_wc_parse_externals_description3() to get them represented as an array of svn_wc_external_item2_t.
Re: svn commit: r1657267 - in /subversion/branches/pin-externals/subversion: include/svn_client.h libsvn_client/copy.c libsvn_client/deprecated.c svn/copy-cmd.c tests/libsvn_client/client-test.c
On 04.02.2015 15:59, s...@apache.org wrote: > Author: stsp > Date: Wed Feb 4 14:58:59 2015 > New Revision: 1657267 > > URL: http://svn.apache.org/r1657267 > Log: > On the pin-externals branch, allow fine-grained API-level control over which > externals get pinned during a copy. This feature is intended for clients which > allow users to select specific externals for pinning, like TortoiseSVN does. [...] > @@ -4523,6 +4531,7 @@ svn_client_copy7(const apr_array_header_ > svn_boolean_t make_parents, > svn_boolean_t ignore_externals, > svn_boolean_t pin_externals, > + const apr_hash_t *externals_to_pin, > const apr_hash_t *revprop_table, > svn_commit_callback2_t commit_callback, > void *commit_baton, .../subversion/bindings/javahl/native/SVNClient.cpp:463:17: error: no matching function for call to 'svn_client_copy7' SVN_JNI_ERR(svn_client_copy7(srcs, destinationPath.c_str(), ^~~~ .../subversion/bindings/javahl/native/JNIUtil.h:234:39: note: expanded from macro 'SVN_JNI_ERR' svn_error_t *svn_jni_err__temp = (expr);\ ^ .../subversion/include/svn_client.h:4528:1: note: candidate function not viable: requires 12 arguments, but 11 were provided -- Brane
Re: [vote] pin-externals branch to trunk
On 04.02.2015 19:08, Stefan Sperling wrote: On Wed, Feb 04, 2015 at 06:42:08PM +0100, Stefan Kueng wrote: Maybe one more improvement: Add a new API to fetch the list of externals which would be pegged if NULL is passed to the svn_client_copy7 API. Suggested name: svn_client_get_externals_for_copy() which returns the hash of all externals. I figure the code to do that is already in place (you have to do that if NULL is passed). And it would make it easier for clients. I can easily do this myself on a working copy, but I'm guessing I can't do it using the client API's as efficiently as a new API could for urls. A recursive propget on the copy source gives you that list. Plus you'd have to pass the externals you get through svn_wc_parse_externals_description3() to get them represented as an array of svn_wc_external_item2_t. Thanks for the hint. Will do that. Stefan
[PATCH] Fix possible crash in svn_fs_fs__lock() / svn_fs_fs__unlock()
Hi!
Recenty I've discovered possible crash in FSFS locking code. If, for some
reason, 'write-lock' cannot be obtained for lock/unlock operation, the FSFS
will SEGFAULT.
This happens beacuse lb.infos field is getting initialized only in function
lock_body() (see the code below). So, if svn_fs_fs__with_write_lock() fails
without actual invoking the lock_body(), lb.infos will be left uninitialized.
[[[
svn_error_t *
svn_fs_fs__lock(svn_fs_t *fs,
...
struct lock_baton lb;
...
lb.fs = fs;
lb.targets = sorted_targets;
lb.comment = comment;
lb.is_dav_comment = is_dav_comment;
lb.expiration_date = expiration_date;
lb.steal_lock = steal_lock;
lb.result_pool = result_pool;
err = svn_fs_fs__with_write_lock(fs, lock_body, &lb, scratch_pool);
for (i = 0; i < lb.infos->nelts; ++i)
{
...
]]]
The same thing with svn_fs_fs__unlock().
I've attached the patch with crashing test and simple fix for this issue.
Log message:
[[[
Fix possible crash in svn_fs_fs__lock() / svn_fs_fs__unlock().
* subversion/subversion/tests/libsvn_fs/locks-test.c
(obtain_write_lock_failure_test): New; test for the issue.
* subversion/subversion/libsvn_fs_fs/lock.c
(lock_body,
svn_fs_fs__lock): Initialize the lb.infos field before calling to
svn_fs_fs__with_write_lock().
(unlock_body,
svn_fs_fs__unlock): Same.
Patch by: Sergey Raevskiy
]]]
Index: subversion/libsvn_fs_fs/lock.c
===
--- subversion/libsvn_fs_fs/lock.c (revision 1657295)
+++ subversion/libsvn_fs_fs/lock.c (working copy)
@@ -853,9 +853,6 @@ lock_body(void *baton, apr_pool_t *pool)
int i, outstanding = 0;
apr_pool_t *iterpool = svn_pool_create(pool);
- lb->infos = apr_array_make(lb->result_pool, lb->targets->nelts,
- sizeof(struct lock_info_t));
-
/* Until we implement directory locks someday, we only allow locks
on files or non-existent paths. */
/* Use fs->vtable->foo instead of svn_fs_foo to avoid circular
@@ -1056,9 +1053,6 @@ unlock_body(void *baton, apr_pool_t *pool)
int i, max_components = 0, outstanding = 0;
apr_pool_t *iterpool = svn_pool_create(pool);
- ub->infos = apr_array_make(ub->result_pool, ub->targets->nelts,
- sizeof(struct unlock_info_t));
-
SVN_ERR(ub->fs->vtable->youngest_rev(&youngest, ub->fs, pool));
SVN_ERR(ub->fs->vtable->revision_root(&root, ub->fs, youngest, pool));
@@ -1240,6 +1234,8 @@ svn_fs_fs__lock(svn_fs_t *fs,
lb.fs = fs;
lb.targets = sorted_targets;
+ lb.infos = apr_array_make(result_pool, sorted_targets->nelts,
+sizeof(struct lock_info_t));
lb.comment = comment;
lb.is_dav_comment = is_dav_comment;
lb.expiration_date = expiration_date;
@@ -1330,6 +1326,8 @@ svn_fs_fs__unlock(svn_fs_t *fs,
ub.fs = fs;
ub.targets = sorted_targets;
+ ub.infos = apr_array_make(result_pool, sorted_targets->nelts,
+sizeof(struct unlock_info_t));
ub.skip_check = FALSE;
ub.break_lock = break_lock;
ub.result_pool = result_pool;
Index: subversion/tests/libsvn_fs/locks-test.c
===
--- subversion/tests/libsvn_fs/locks-test.c (revision 1657295)
+++ subversion/tests/libsvn_fs/locks-test.c (working copy)
@@ -1079,6 +1079,62 @@ lock_cb_error(const svn_test_opts_t *opts,
return SVN_NO_ERROR;
}
+static svn_error_t *
+obtain_write_lock_failure_test(const svn_test_opts_t *opts,
+ apr_pool_t *pool)
+{
+ svn_fs_t *fs;
+ const char *conflict;
+ svn_revnum_t newrev;
+ svn_fs_access_t *access;
+ svn_fs_lock_target_t *target;
+ struct lock_many_baton_t baton;
+ apr_hash_t *lock_paths, *unlock_paths;
+
+ /* The test makes sense only for FSFS. */
+ if (strcmp(opts->fs_type, SVN_FS_TYPE_FSFS) != 0)
+return svn_error_create(SVN_ERR_TEST_SKIPPED, NULL,
+"this will test FSFS repositories only");
+
+ SVN_ERR(create_greek_fs(&fs, &newrev, "obtain-write-lock-failure-test",
+ opts, pool));
+ SVN_ERR(svn_fs_create_access(&access, "bubba", pool));
+ SVN_ERR(svn_fs_set_access(fs, access));
+
+ /* Make a read only 'write-lock' file. This prevents any write operations
+ from being executed. */
+
SVN_ERR(svn_io_set_file_read_only("obtain-write-lock-failure-test/write-lock",
+TRUE, pool));
+
+ baton.results = apr_hash_make(pool);
+ baton.pool = pool;
+ baton.count = 0;
+
+ /* Trying to lock some paths. We don't really care about error; the test
+ shouldn't crash. */
+ target = svn_fs_lock_target_create(NULL, newrev, pool);
+ lock_paths = apr_hash_make(pool);
+ svn_hash_sets(lock_paths, "/iota", target);
+ svn_hash_sets(lock_paths, "/A/mu", target);
+
+ apr_hash_clear(baton.results);
+ SVN_TEST_ASSERT_ANY_ERROR(svn_fs_lock_many(fs, lock_paths, "comme
[no subject]
ゆうちょのATMは9時からだったので、それまで待ってからお金おろして帰りますね --
Re: svn commit: r1657451 - in /subversion/branches/reuse-ra-session: ./ subversion/libsvn_client/
On 05.02.2015 01:44, br...@apache.org wrote: > Author: brane > Date: Thu Feb 5 00:44:57 2015 > New Revision: 1657451 > > URL: http://svn.apache.org/r1657451 > Log: > On the reuse-ra-session branch: Add explicit session reuse in libsvn_client. Anyone who's interested in the RA session cache, please take time to review this commit. All tests pass for me (ra_local, ra_svn and ra_dav) and I re-read the diffs about five times to check that sessions are being released to cache only when it's certain that they're valid. But I'd really like to have a few more pairs of eyes on this, because there's potential for some nasty bugs being introduced. -- Brane
