Re: [svnbench] Revision: 1091976 compiled Apr 14 2011, 00:21:28
On Fri, 15 Apr 2011 01:25 +0200, "Neels Hofmeyr" wrote: > So, does anyone do Windows? Do you speak bash, python and BAT? Want to > know about perf on your setup? I'll gladly send you my scripts Just add them to public version control? > and explain anything you want to know about it.
Re: some more performance benchmarks
On Thu, Apr 7, 2011 at 10:42, Neels Hofmeyr wrote: >... > Any ideas/opinions about adding to tools/dev/ would be appreciated. Commited in r1092569 as tools/dev/benchmarks/suite1. Having them in source control is better than worrying too much about the naming. We can now evolve these for other platforms, people can run them on their OS, etc. Cheers, -g
Re: [svnbench] Revision: 1091976 compiled Apr 14 2011, 00:21:28
Hi Neels, I have a brand new (2 week old) MacBook Pro with 4 GB RAM. I am more than happy to run your scripts if you like. On the same machine I have 1.6.16 (and trunk r1092145) installed - so I can do a comparison run of both. And if you think it is worthy of another comparison run, I have a 3 year old MacBook (non-Pro in flavour) that could also have the same runs. Beau. On 15/04/2011, at 9:25 AM, Neels Hofmeyr wrote: > On Thu, 2011-04-14 at 23:22 +0200, Johan Corveleyn wrote: >> Hi Neels, >> >> Great work, and good to see those numbers. But ... hold on a minute >> before jumping to conclusions. IIUC you only tested one type of >> platform: *nix with local disk (on a (powerful) VM, and on a (slightly >> less powerful) "real machine"). It gives a good indication, but it's >> definitely not enough to declare trunk release worthy >> performance-wise. > > I'm aware of that and am usually very careful to place "I'd say" and > "IMHO" all around my humble "conclusions" ;) > > As-is, my scripts definitely won't run on Windows. The core is python, > but there's a thin layer of bash around it that calls the python with > the desired settings and filenames, so the bash stuff needs to be looked > at and translated to BAT ...or python probably. > It could work on OSX without changes, AFAIK. > Frankly, I won't personally go into testing on Windows or a WC on an NFS > mount, because, *IMHO*, both Win and WC-on-NFS are misguided, and I > personally can't be bothered. This is where people using those things > and whose jobs depend on svn 1.7 doing well on them should get involved, > as far as I'm concerned. > > Johan is right to highlight the limitations. And I can add a large > portion of limitations inherent to benchmarks like these (hardware > particulars, time measurement inaccuracies, simulation validity, > statistics, interpretation, selective perception, chance,... ). Only the > actual release 1.7.0 will bring all the real issues to the surface. > > And yet, the conclusion I find from my past and present test runs is: > the performance I have seen in my setup a while back has definitely been > a show-stopper. And now I don't see those particular show-stoppers > anymore. So, yes, I should probably be more clear instead of saying > "release-worthy" -- I meant it rather negatively defined, as in: my > personal perf show-stoppers have vanished. (Thanks for poking) > > So, does anyone do Windows? Do you speak bash, python and BAT? Want to > know about perf on your setup? I'll gladly send you my scripts and > explain anything you want to know about it. > > Oh, and about the time factors getting much better on the VM -- that's > not just because the VM is faster than my home machines, since then > 1.6.x would also be faster on the VM, resulting in similar time factors > as on other hardware. I don't know in detail why we're seeing this, but > it must be something like, maybe SQlite has some magic that enhances > performance when -- I don't know -- the CPU bus is very wide, or disk > cache is fast, or something like that, boosting fast hardware even more. > It must be something that svn 1.6 can't benefit from. > > Enough talk :) > > ~Neels > > > >> >> For all we know there could be a massive regression on Windows or >> MacOS, or on NTFS specifically (like the locking in WC-1, which was >> orders of magnitude slower on Windows/NTFS than on Linux), or, as >> already hinted a few times by Philip, on network-mounted filesystems: >> NFS, CIFS, ... >> >> So, to get a better picture, your test-suite should be run on a >> variety of platforms (others can help, I guess, like with Mark's >> perf-tests). Can your test-suite be run "as is" by others on Windows >> for example? Maybe you could already run it yourself on an NFS-mounted >> volume? >> >> I think we need to at least test [ *nix | Windows | MacOS ] x [ local >> disk | remote disk ] (ok maybe *nix is too coarse-grained, as is local >> disk etc..., but you get the picture). >> >> Cheers, > >
No GSOC proposals for Subversion
I've been looking at the GSoC proposals for Apache, and there doesn't seem to be one for Subversion. There was one about making the test suite run in production, but it's gone now. Are we quit of that chore for this season then? ;) -- Brane
Re: Find a deleted file and WC-NG
Awesome, thanks Mike. I'll certainly have a play and see what I can achieve... On 15/04/2011, at 3:07 AM, C. Michael Pilato wrote: > On 04/13/2011 10:55 PM, Gavin "Beau" Baumanis wrote: >> If the information is appropriately stored in the repository, and can be >> resolved somewhat via doing svn log / text searches; Why can't a >> function ; getTheLastRevisionAndPathThisFileExisted(filename, >> repo://startingPath); be created? that does that process for me under the >> hood? > > We have an RA function, svn_ra_get_deleted_rev(path, peg_rev, end_rev) and a > corresponding repos API function svn_repos_get_deleted_rev(path, start, end) > which might do what you are looking for. Maybe that could serve as at least > a starting point as you investigate how to make Subversion do what you want > here? > > -- > C. Michael Pilato > CollabNet <> www.collab.net <> Distributed Development On Demand >
Re: [svnbench] Revision: 1091976 compiled Apr 14 2011, 00:21:28
On Thu, 2011-04-14 at 23:22 +0200, Johan Corveleyn wrote: > Hi Neels, > > Great work, and good to see those numbers. But ... hold on a minute > before jumping to conclusions. IIUC you only tested one type of > platform: *nix with local disk (on a (powerful) VM, and on a (slightly > less powerful) "real machine"). It gives a good indication, but it's > definitely not enough to declare trunk release worthy > performance-wise. I'm aware of that and am usually very careful to place "I'd say" and "IMHO" all around my humble "conclusions" ;) As-is, my scripts definitely won't run on Windows. The core is python, but there's a thin layer of bash around it that calls the python with the desired settings and filenames, so the bash stuff needs to be looked at and translated to BAT ...or python probably. It could work on OSX without changes, AFAIK. Frankly, I won't personally go into testing on Windows or a WC on an NFS mount, because, *IMHO*, both Win and WC-on-NFS are misguided, and I personally can't be bothered. This is where people using those things and whose jobs depend on svn 1.7 doing well on them should get involved, as far as I'm concerned. Johan is right to highlight the limitations. And I can add a large portion of limitations inherent to benchmarks like these (hardware particulars, time measurement inaccuracies, simulation validity, statistics, interpretation, selective perception, chance,... ). Only the actual release 1.7.0 will bring all the real issues to the surface. And yet, the conclusion I find from my past and present test runs is: the performance I have seen in my setup a while back has definitely been a show-stopper. And now I don't see those particular show-stoppers anymore. So, yes, I should probably be more clear instead of saying "release-worthy" -- I meant it rather negatively defined, as in: my personal perf show-stoppers have vanished. (Thanks for poking) So, does anyone do Windows? Do you speak bash, python and BAT? Want to know about perf on your setup? I'll gladly send you my scripts and explain anything you want to know about it. Oh, and about the time factors getting much better on the VM -- that's not just because the VM is faster than my home machines, since then 1.6.x would also be faster on the VM, resulting in similar time factors as on other hardware. I don't know in detail why we're seeing this, but it must be something like, maybe SQlite has some magic that enhances performance when -- I don't know -- the CPU bus is very wide, or disk cache is fast, or something like that, boosting fast hardware even more. It must be something that svn 1.6 can't benefit from. Enough talk :) ~Neels > > For all we know there could be a massive regression on Windows or > MacOS, or on NTFS specifically (like the locking in WC-1, which was > orders of magnitude slower on Windows/NTFS than on Linux), or, as > already hinted a few times by Philip, on network-mounted filesystems: > NFS, CIFS, ... > > So, to get a better picture, your test-suite should be run on a > variety of platforms (others can help, I guess, like with Mark's > perf-tests). Can your test-suite be run "as is" by others on Windows > for example? Maybe you could already run it yourself on an NFS-mounted > volume? > > I think we need to at least test [ *nix | Windows | MacOS ] x [ local > disk | remote disk ] (ok maybe *nix is too coarse-grained, as is local > disk etc..., but you get the picture). > > Cheers,
RE: svn commit: r1092530 - in /subversion/trunk/subversion/libsvn_wc: status.c update_editor.c wc.h
On Apr 14, 2011 6:35 PM, "Bert Huijben" wrote: > > > > > -Original Message- > > From: Greg Stein [mailto:gst...@gmail.com] > > Sent: vrijdag 15 april 2011 0:25 > > To: dev@subversion.apache.org > > Subject: Re: svn commit: r1092530 - in > > /subversion/trunk/subversion/libsvn_wc: status.c update_editor.c wc.h > > > > - SVN_ERR(svn_wc__internal_walk_children(db, local_abspath, > > > - FALSE /* show_hidden */, > > > - modcheck_found_node, > &modcheck_baton, > > > - svn_depth_infinity, > cancel_func, > > > - cancel_baton, pool)); > > > + /* Walk the WC tree for status with depth infinity, looking for any > local > > > + * modifications. If it's a "sparse" directory, that's OK: there can > be > > > + * no local mods in the pieces that aren't present in the WC. */ > > > + > > > + err = svn_wc__internal_walk_status(db, local_abspath, > > > > How can this work for a file? It looks like walk_status will fail for > > non-directory nodes. It calls get_dir_status() which then tries to > > read children info and fetch dirents. > > Walk status properly detects this case and has no problem with walking only > a single file in a directory. This is essentially what libsvn_client does > for its status walk when it is not looking at a repository. > (This is managed by the 'selected' argument of get_dir_status) Ah! I see now. It pops up to the containing directory and picks out that one. Thanks, -g
RE: svn commit: r1092530 - in /subversion/trunk/subversion/libsvn_wc: status.c update_editor.c wc.h
> -Original Message- > From: Greg Stein [mailto:gst...@gmail.com] > Sent: vrijdag 15 april 2011 0:25 > To: dev@subversion.apache.org > Subject: Re: svn commit: r1092530 - in > /subversion/trunk/subversion/libsvn_wc: status.c update_editor.c wc.h > > - SVN_ERR(svn_wc__internal_walk_children(db, local_abspath, > > - FALSE /* show_hidden */, > > - modcheck_found_node, &modcheck_baton, > > - svn_depth_infinity, cancel_func, > > - cancel_baton, pool)); > > + /* Walk the WC tree for status with depth infinity, looking for any local > > + * modifications. If it's a "sparse" directory, that's OK: there can be > > + * no local mods in the pieces that aren't present in the WC. */ > > + > > + err = svn_wc__internal_walk_status(db, local_abspath, > > How can this work for a file? It looks like walk_status will fail for > non-directory nodes. It calls get_dir_status() which then tries to > read children info and fetch dirents. Walk status properly detects this case and has no problem with walking only a single file in a directory. This is essentially what libsvn_client does for its status walk when it is not looking at a repository. (This is managed by the 'selected' argument of get_dir_status) Bert
Re: svn commit: r1092530 - in /subversion/trunk/subversion/libsvn_wc: status.c update_editor.c wc.h
On Thu, Apr 14, 2011 at 18:04, wrote:
>...
> +++ subversion/trunk/subversion/libsvn_wc/status.c Thu Apr 14 22:04:55 2011
> @@ -2370,28 +2370,30 @@ svn_wc_get_status_editor5(const svn_delt
>...
> +svn_wc__internal_walk_status(svn_wc__db_t *db,
> + const char *local_abspath,
> + svn_depth_t depth,
> + svn_boolean_t get_all,
> + svn_boolean_t no_ignore,
> + svn_boolean_t ignore_text_mods,
> + const apr_array_header_t *ignore_patterns,
> + svn_wc_status_func4_t status_func,
> + void *status_baton,
> + svn_wc_external_update_t external_func,
> + void *external_baton,
> + svn_cancel_func_t cancel_func,
> + void *cancel_baton,
> + apr_pool_t *scratch_pool)
> {
> - svn_node_kind_t kind;
> struct walk_status_baton wb;
> const svn_io_dirent2_t *dirent;
> const char *anchor_abspath, *target_name;
> svn_boolean_t skip_root;
> + svn_error_t *err;
> + svn_wc__db_status_t status;
> + svn_wc__db_kind_t kind;
status is not used.
>...
> +++ subversion/trunk/subversion/libsvn_wc/update_editor.c Thu Apr 14 22:04:55
> 2011
>...
> @@ -1261,30 +1220,39 @@ modcheck_found_node(const char *local_ab
> * *ALL_EDITS_ARE_DELETES to true, set it to false otherwise. LOCAL_ABSPATH
> * may be a file or a directory. */
> static svn_error_t *
> -tree_has_local_mods(svn_boolean_t *modified,
> +node_has_local_mods(svn_boolean_t *modified,
> svn_boolean_t *all_edits_are_deletes,
> svn_wc__db_t *db,
> const char *local_abspath,
> svn_cancel_func_t cancel_func,
> void *cancel_baton,
> - apr_pool_t *pool)
> + apr_pool_t *scratch_pool)
> {
> - modcheck_baton_t modcheck_baton = { NULL, FALSE, TRUE };
> + modcheck_baton_t modcheck_baton = { NULL, FALSE, FALSE };
> + svn_error_t *err;
>
> modcheck_baton.db = db;
>
> - /* Walk the WC tree to its full depth, looking for any local modifications.
> - * If it's a "sparse" directory, that's OK: there can be no local mods in
> - * the pieces that aren't present in the WC. */
> -
> - SVN_ERR(svn_wc__internal_walk_children(db, local_abspath,
> - FALSE /* show_hidden */,
> - modcheck_found_node,
> &modcheck_baton,
> - svn_depth_infinity, cancel_func,
> - cancel_baton, pool));
> + /* Walk the WC tree for status with depth infinity, looking for any local
> + * modifications. If it's a "sparse" directory, that's OK: there can be
> + * no local mods in the pieces that aren't present in the WC. */
> +
> + err = svn_wc__internal_walk_status(db, local_abspath,
How can this work for a file? It looks like walk_status will fail for
non-directory nodes. It calls get_dir_status() which then tries to
read children info and fetch dirents.
>...
> @@ -1596,32 +1564,16 @@ check_tree_conflict(svn_wc_conflict_desc
>
> /* Check if the update wants to delete or replace a locally
> * modified node. */
> - switch (working_kind)
> - {
> - case svn_wc__db_kind_file:
> - case svn_wc__db_kind_symlink:
Seems that something like this needs to stick around.
If not, then note that the 'working_kind' parameter is no longer used.
>...
Cheers,
-g
Re: svn commit: r1091262 - /subversion/trunk/subversion/libsvn_wc/wc_db.c
On Wed, Apr 13, 2011 at 1:49 PM, Greg Stein wrote: > On Tue, Apr 12, 2011 at 18:19, Hyrum K Wright wrote: >>... >>> Yes, but the statement itself can be attacked if you manually build it. With >>> static text, that is not possible. Attackers cannot alter the semantics in >>> any way. >> >> I guess I'm just dense, because I can't come up with a scenario in >> which a dynamic statement is more prone to injection than a static >> one, as long as both escape their arguments correctly. Dynamic >> queries are more complex, it is true, so I don't recommend using them >> liberally, but I'm not sure banning them outright is the answer. > > In order to best answer this, I investigated the current code... and > now understand why you're probably confused about my assertion :-P > > The construct_filter() function (which was outside the scope of the > diff) creates N *bind* parameters, rather than direct substitution of > the values. N bindable parameters doesn't have any obvious attack > (other than N=HUGE). I missed the diff after the prepare which shows > the 'changelists' array being bound to the prepared statement. > > I'm assuming you already know the attack vector if the values had been > substituted straight into the statement for preparation (ie. class sql > injection), so I won't belabor that point. > > So... yes, this particular usage seems safe, after I got a chance to > see the parts outside of the diff. > > But I'm still very concerned about svn_sqlite__prepare existing. I > want to get rid of that, to ensure that a future developer doesn't see > it and go "ooh! lemme just strcat some stuff together and pass it to > prepare..." ... more below. I still think that's painting with quite a broad brush, but since we've found an alternative solution for this (and similar cases), I'm happy to let it go. We've got version control, we can always resurrect that API if needed. >>... >>> I understand, and would suggest an alternative if I had one right now. I >>> feel the same as you about "not that rock, another". >> >> While riding my bike this afternoon, I came up with an alternate >> proposal. The *common* case is one or zero changelists, so we could >> just have two queries, one for each of those scenarios. In the >> uncommon case that the changelist filter contains multiple >> changelists, we'd just iterate over them using the single changelist >> query. I think this approach is generalizable to other operations >> which use changelist filtering. > > Ooh, yes! I definitely like this approach. > > How about this, for fair trade: I convert the code to the above, in > penance for raising the red flag? :-P ... I take it you'd be fine with > changing the code to follow the above algorithm? And with that change, > then I can follow up with making prepare() a private function to > svn_sqlite.c. Sounds great! Thanks, -Hyrum
Re: Case-only renames on Windows (issue #3702)
On Tue, Apr 12, 2011 at 11:14 PM, Johan Corveleyn wrote:
> On Fri, Mar 25, 2011 at 2:21 PM, Johan Corveleyn wrote:
>> On Sun, Mar 20, 2011 at 9:32 PM, Johan Corveleyn wrote:
>>> Some thoughts:
>>>
>>> - There is only a problem if the dst_path gets case-normalized to one
>>> of the source paths. Otherwise, the case-normalization really does
>>> need to happen.
>>
>> Hm, this thought may be incorrect (or at least "unexpected" for
>> windows users). In fact, if we look at how the native "move" behaves,
>> it never case-normalizes the target path:
>>
>> [[[
>> C:\Temp>dir /B test
>> TODO
>>
>> C:\Temp>echo anothertest > bla
>>
>> C:\Temp>move bla test\toDO
>> Overwrite C:\Temp\test\toDO? (Yes/No/All): y
>> 1 file(s) moved.
>>
>> C:\Temp>dir /B test
>> toDO
>>
>> C:\Temp>type test\todo
>> anothertest
>> ]]]
>>
>> So it seems that, if we want "svn mv" to behave more like "move" on
>> Windows, the target path should never be normalized to the on-disk
>> casing. Just use it as is ...
>
> Finally getting around to this again ... the above is still an open
> question for specifying the desired behavior of "svn move" on Win32
> ... If there is a file A on disk, what should "svn move B a" do?
>
> In theory it could generate a replace of A by a ("copied from" B).
> That would be consistent with behavior of Windows' "move" command,
> after confirming the overwrite.
>
> But, lacking the "confirm-for-overwrite", I guess the behavior most
> consistent with existing svn functionality would be to refuse this
> move in the same way as "svn move B A" is refused. Currently, this is
> with the (slightly not-to-the-point) error message: "svn: E155007:
> Path 'C:\temp\bla\A' is not a directory".
>
> Would that be ok?
I think this would be ok: just refuse a move that overwrites another
local file (need to rm it first).
Now, I just realized that case-only renames (or renames in general)
only come into play when there are exactly 2 "targets" of the move
command: the source and the destination (ok, I'm a bit slow, I know
:-)).
So, for fixing issue #3702 (case-only renames on Windows), if we take
into account the rest that's been discussed in this thread, we only
need to do something special:
- If there are exactly 2 targets
- If those targets are paths, rather than uris.
- If normalized dst_path == normalized src_path
In that case I think we should either:
1) Normalize the original dst_path again, but this time without the
APR_FILEPATH_TRUENAME flag to apr_filepath_merge, so it isn't
converted to on-disk-representation.
or
2) Just use the original dst_path as it was passed to the client, un-normalized.
I have no idea if it should be 1) (other important normalization-stuff
going on besides converting it to the on-disk-representation, that
should still be performed in this case) or 2) ("if the user tells us
to use this particular representation of the path, let's use it").
Option 2) would of course be much easier. For option 1) code needs to
be written/copy-pasted/refactored to do all the normalization stuff,
except passing the flag to apr_filepath_merge.
Thoughts?
Cheers,
--
Johan
Re: [svnbench] Revision: 1091976 compiled Apr 14 2011, 00:21:28
On Thu, Apr 14, 2011 at 3:33 PM, Neels Hofmeyr wrote: > Hi all, > > yesterday's and today's benchmarks look particularly good (listed > below). I haven't paid attention to commits, but it seems some pretty > good perf commits have happened recently (except for 'svn delete'). > All in all, once we clarified why 'svn delete' is as slow (and possibly > choose not to worry about it), I'd suggest that trunk's performance is > release worthy when compared to 1.6.x. Hi Neels, Great work, and good to see those numbers. But ... hold on a minute before jumping to conclusions. IIUC you only tested one type of platform: *nix with local disk (on a (powerful) VM, and on a (slightly less powerful) "real machine"). It gives a good indication, but it's definitely not enough to declare trunk release worthy performance-wise. For all we know there could be a massive regression on Windows or MacOS, or on NTFS specifically (like the locking in WC-1, which was orders of magnitude slower on Windows/NTFS than on Linux), or, as already hinted a few times by Philip, on network-mounted filesystems: NFS, CIFS, ... So, to get a better picture, your test-suite should be run on a variety of platforms (others can help, I guess, like with Mark's perf-tests). Can your test-suite be run "as is" by others on Windows for example? Maybe you could already run it yourself on an NFS-mounted volume? I think we need to at least test [ *nix | Windows | MacOS ] x [ local disk | remote disk ] (ok maybe *nix is too coarse-grained, as is local disk etc..., but you get the picture). Cheers, -- Johan
Re: Layering violations in the FS cache code? (was "svn commit: r1091573 - /subversion/trunk/build.conf")
On 14.04.2011 21:03, Daniel Shahaf wrote: > On Thu, 14 Apr 2011 14:43 -0400, "C. Michael Pilato" > wrote: >> On 04/13/2011 06:52 PM, Stefan Fuhrmann wrote: >>> The code in question has evolved over many months so it is >>> very possible that the name of svn_fs_get_cache_config() >>> and friends is no longer appropriate. The same goes for the >>> place that this has been implemented. >>> >>> From a design perspective, I think it is perfectly to o.k. to >>> expose resource limits on the server UI level. The fact that FSFS >>> is currently the only part of the server that uses these settings >>> does not change, IMO, the fact that they are part of the UI. >> I don't have an opinion about exposing resource limits via the server >> UI. I do have a strong opinion about the code honoring the flow of the >> layered library design we have. If you want to tweak server settings >> from client code, you need to do so via the RA vtable(), implementing >> the logic to do so (or to expressed *not* do so) in every RA provider. >> >> On 04/13/2011 06:52 PM, Stefan Fuhrmann wrote: >>> Maybe we should simply move the function in question to libsvn_subr >>> and rename them properly. >> On 04/13/2011 11:12 PM, Daniel Shahaf wrote: >>> I assumed the resolution would be to move that function to libsvn_fs, not >>> to libsvn_subr... >> I'm honestly not quite sure exactly where the right place is. I don't >> really see what moving it to libsvn_fs does for us -- IMO, it's still >> wrong for svn_ra_initialize() call into that. (libsvn_ra should only >> call into libsvn_subr, libsvn_delta, and its own RA provider vtable.) > Would svn_cmdline_init() be a better place to call the init > function from? Clearly not, since that function is a startup helper for command-line programs, not for libraries. -- Brane
RE: svn commit: r1091187 - in /subversion/trunk/subversion: include/svn_wc.h libsvn_client/switch.c libsvn_client/update.c libsvn_wc/deprecated.c libsvn_wc/update_editor.c
> -Original Message- > From: Julian Foad [mailto:julian.f...@wandisco.com] > Sent: dinsdag 12 april 2011 18:03 > To: dev@subversion.apache.org > Cc: comm...@subversion.apache.org > Subject: Re: svn commit: r1091187 - in /subversion/trunk/subversion: > include/svn_wc.h libsvn_client/switch.c libsvn_client/update.c > libsvn_wc/deprecated.c libsvn_wc/update_editor.c > > Hi Bert. A question about the "server handles [depth] filtering" > flag... > > On Mon, 2011-04-11, rhuij...@apache.org wrote: > > Author: rhuijben > > Date: Mon Apr 11 19:58:27 2011 > > New Revision: 1091187 > > > > URL: http://svn.apache.org/viewvc?rev=1091187&view=rev > > Log: > > Update the svn_wc_get_update_editor3() and > svn_wc_get_switch_editor3() apis > > to accept two new booleans: One to allow disabling the automatic > conversion > > of local additions into modifications and one to allow disabling the depth > > filter (Which is only needed when talking to pre 1.5 servers). > > > > Disabling the depth filter allows avoiding many db operations (should be > set by > > libsvn_client when it knows the server understands depth), while the local > > additions filter is for clients that prefer to explicitly handle tree > > conflicts over the update editor magic. > > > > * subversion/include/svn_wc.h > > (svn_wc_get_update_editor4): Update prototype and documentation > > (svn_wc_get_update_editor3): Update documentation. > > (svn_wc_get_update_switch4): Update prototype and documentation > > (svn_wc_get_update_switch3): Update documentation. > > > > * subversion/libsvn_client/switch.c > > (switch_internal): Update caller. Report that the server handles depth > when > > depth is unknown. > [...] > > > Modified: subversion/trunk/subversion/include/svn_wc.h > > URL: > http://svn.apache.org/viewvc/subversion/trunk/subversion/include/svn_wc > .h?rev=1091187&r1=1091186&r2=1091187&view=diff > > > == > > > --- subversion/trunk/subversion/include/svn_wc.h (original) > > +++ subversion/trunk/subversion/include/svn_wc.h Mon Apr 11 19:58:27 > 2011 > > @@ -5302,6 +5302,9 @@ typedef svn_error_t *(*svn_wc_get_file_t > > * If @a allow_unver_obstructions is TRUE, then allow unversioned > > * obstructions when adding a path. > > * > > + * If @a adds_as_modification is TRUE, local additions are seen as a local > > + * modification of added nodes when the node kind matches. > > + * > > * If @a depth is #svn_depth_infinity, update fully recursively. > > * Else if it is #svn_depth_immediates, update the uppermost > > * directory, its file entries, and the presence or absence of > > @@ -5315,6 +5318,10 @@ typedef svn_error_t *(*svn_wc_get_file_t > > * #svn_depth_unknown, then in addition to updating PATHS, also set > > * their sticky ambient depth value to @a depth. > > * > > + * If @a repository_performs_filtering is TRUE, assume that the server > handles > > + * the ambient depth filtering, so this doesn't have to be handled in the > > + * editor. > > + * > > * @since New in 1.7. > > */ > > svn_error_t * > > @@ -5328,6 +5335,8 @@ svn_wc_get_update_editor4(const svn_delt > >svn_depth_t depth, > >svn_boolean_t depth_is_sticky, > >svn_boolean_t allow_unver_obstructions, > > + svn_boolean_t adds_as_modification, > > + svn_boolean_t server_performs_filtering, > >const char *diff3_cmd, > >const apr_array_header_t *preserved_exts, > >svn_wc_conflict_resolver_func_t conflict_func, > > @@ -5344,7 +5353,8 @@ svn_wc_get_update_editor4(const svn_delt > > /** Similar to svn_wc_get_update_editor4, but uses access batons and > relative > > * path instead of a working copy context-abspath pair and > > * svn_wc_traversal_info_t instead of an externals callback. Also, > > - * @a fetch_func and @a fetch_baton are ignored. > > + * @a fetch_func and @a fetch_baton are ignored. Always sets > > + * server_performs_filtering to FALSE. > > * > > * If @a ti is non-NULL, record traversal info in @a ti, for use by > > * post-traversal accessors such as svn_wc_edited_externals(). > > @@ -5352,6 +5362,9 @@ svn_wc_get_update_editor4(const svn_delt > > * All locks, both those in @a anchor and newly acquired ones, will be > > * released when the editor driver calls @c close_edit. > > * > > + * Always sets @a adds_as_modification to TRUE and @a > server_performs_filtering > > + * to FALSE. > > + * > > * @since New in 1.5. > > * @deprecated Provided for backward compatibility with the 1.6 API. > > */ > > @@ -5454,6 +5467,8 @@ svn_wc_get_switch_editor4(const svn_delt > >svn_depth_t depth, > >svn_boolean_t depth_is_sticky, > >svn_boolean_t allow_unver_ob
Re: svn commit: r1092446 - in /subversion/trunk/subversion: svn/notify.c tests/cmdline/merge_tests.py tests/cmdline/svntest/actions.py tests/cmdline/update_tests.py
On 04/14/2011 03:30 PM, hwri...@apache.org wrote: > Author: hwright > Date: Thu Apr 14 19:30:04 2011 > New Revision: 1092446 > > URL: http://svn.apache.org/viewvc?rev=1092446&view=rev > Log: > UI tweak: Use ':' in place of '...' in the update start notification. > > This is a bit of a bikeshed, but the denizens of IRC seemed to be in agreement > that it was a useful tweak. Oh, +1. -- C. Michael Pilato CollabNet <> www.collab.net <> Distributed Development On Demand signature.asc Description: OpenPGP digital signature
Re: Why do we include debug symbols in !maintainer_mode?
[Hyrum K Wright] > Although I don't know if this has any impact on the processor > i-cache, I still don't see much reason for using '-g -O2' in > non-maintainer mode. As others have said, no, it should have no effect on the icache, at least on systems I know (mainly ELF). The debug section isn't even loaded into memory at runtime, it's just sitting there eating disk until someone like gdb comes along and reads it explicitly. With my Linux distribution packager hat on, though, I wouldn't mind if the default were changed. I'd change it back so I could provide out-of-band debug symbols in my packages, but overriding CFLAGS at build time is so trivial that anyone doing any special handling like this shouldn't really be inconvenienced. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
Re: Layering violations in the FS cache code? (was "svn commit: r1091573 - /subversion/trunk/build.conf")
On Thu, 14 Apr 2011 14:43 -0400, "C. Michael Pilato" wrote: > On 04/13/2011 06:52 PM, Stefan Fuhrmann wrote: > > The code in question has evolved over many months so it is > > very possible that the name of svn_fs_get_cache_config() > > and friends is no longer appropriate. The same goes for the > > place that this has been implemented. > > > > From a design perspective, I think it is perfectly to o.k. to > > expose resource limits on the server UI level. The fact that FSFS > > is currently the only part of the server that uses these settings > > does not change, IMO, the fact that they are part of the UI. > > I don't have an opinion about exposing resource limits via the server > UI. I do have a strong opinion about the code honoring the flow of the > layered library design we have. If you want to tweak server settings > from client code, you need to do so via the RA vtable(), implementing > the logic to do so (or to expressed *not* do so) in every RA provider. > > On 04/13/2011 06:52 PM, Stefan Fuhrmann wrote: > > Maybe we should simply move the function in question to libsvn_subr > > and rename them properly. > > On 04/13/2011 11:12 PM, Daniel Shahaf wrote: > > I assumed the resolution would be to move that function to libsvn_fs, not > > to libsvn_subr... > > I'm honestly not quite sure exactly where the right place is. I don't > really see what moving it to libsvn_fs does for us -- IMO, it's still > wrong for svn_ra_initialize() call into that. (libsvn_ra should only > call into libsvn_subr, libsvn_delta, and its own RA provider vtable.) Would svn_cmdline_init() be a better place to call the init function from? But, wait, svn_cmdline_* live in libsvn_subr, so they can't call functions implemented in libsvn_fs (not without another layer of indirection). Arrgh. > If we move it all to libsvn_subr -- the common-most utility function > we have to offer -- I would suppose that that would solve this. But > again, I don't understand the code, it usages, or its requirements in > terms of thread-safety and such.
Re: Layering violations in the FS cache code? (was "svn commit: r1091573 - /subversion/trunk/build.conf")
On 04/13/2011 06:52 PM, Stefan Fuhrmann wrote: > The code in question has evolved over many months so it is > very possible that the name of svn_fs_get_cache_config() > and friends is no longer appropriate. The same goes for the > place that this has been implemented. > > From a design perspective, I think it is perfectly to o.k. to > expose resource limits on the server UI level. The fact that FSFS > is currently the only part of the server that uses these settings > does not change, IMO, the fact that they are part of the UI. I don't have an opinion about exposing resource limits via the server UI. I do have a strong opinion about the code honoring the flow of the layered library design we have. If you want to tweak server settings from client code, you need to do so via the RA vtable(), implementing the logic to do so (or to expressed *not* do so) in every RA provider. On 04/13/2011 06:52 PM, Stefan Fuhrmann wrote: > Maybe we should simply move the function in question to libsvn_subr > and rename them properly. On 04/13/2011 11:12 PM, Daniel Shahaf wrote: > I assumed the resolution would be to move that function to libsvn_fs, not > to libsvn_subr... I'm honestly not quite sure exactly where the right place is. I don't really see what moving it to libsvn_fs does for us -- IMO, it's still wrong for svn_ra_initialize() call into that. (libsvn_ra should only call into libsvn_subr, libsvn_delta, and its own RA provider vtable.) If we move it all to libsvn_subr -- the common-most utility function we have to offer -- I would suppose that that would solve this. But again, I don't understand the code, it usages, or its requirements in terms of thread-safety and such. -- C. Michael Pilato CollabNet <> www.collab.net <> Distributed Development On Demand signature.asc Description: OpenPGP digital signature
Re: Why do we include debug symbols in !maintainer_mode?
Philip Martin writes: > Hyrum K Wright writes: > >> Although I don't know if this has any impact on the processor >> i-cache On a Linux system the debug symbols are in separate ELF sections, the loader probaby doesn't even map them into memory. -- Philip
Re: Why do we include debug symbols in !maintainer_mode?
On Thu, 2011-04-14 at 14:25 -0400, Philip Martin wrote: > I believe it is a GNU standard. Debug symbols can be used with an > optimised build although it is obviously easier to debug without > optimisation More specifically: stepping through a -g -O2 executable is pretty painful, but you can still usually get a decent stack trace from one.
Re: svn commit: r1091928 - in /subversion/trunk/subversion: libsvn_client/commit.c tests/cmdline/commit_tests.py
On 04/14/2011 02:08 PM, Hyrum K Wright wrote: > Oh, and I also coded up the original implementation of issue #3242. (Not > the> fix, the implementation) Heheh. -- C. Michael Pilato CollabNet <> www.collab.net <> Distributed Development On Demand signature.asc Description: OpenPGP digital signature
Re: Why do we include debug symbols in !maintainer_mode?
Hyrum K Wright writes: > I just built a version of trunk to use on my "production" working > copies, and configured it without maintainer mode. I noticed that it > was using '-g -O2' in the CFLAGS, which seems completely nonsensical: > debug symbols often refer to stuff that gets optimized away, and just > bloats the final executable. Although I don't know if this has any > impact on the processor i-cache, I still don't see much reason for > using '-g -O2' in non-maintainer mode. > > Some voice in the back of my head says we've had this discussion > before, but I can't seem to find it. I just wanted to check here > before I went and changed things. (And for the record, I hacked my > local Makefile to remove '-g' from CFLAGS.) I believe it is a GNU standard. Debug symbols can be used with an optimised build although it is obviously easier to debug without optimisation Most distributions strip debug symbols from their binary packages automatically. These days GDB supports debug symbols in files separate from the executables, so some distributions have started shipping debug packages that contain the debug symbols for the stripped binaries. -- Philip
Re: svn commit: r1091928 - in /subversion/trunk/subversion: libsvn_client/commit.c tests/cmdline/commit_tests.py
On Thu, Apr 14, 2011 at 12:49 PM, Bert Huijben wrote: > > >> -Original Message- >> From: Hyrum K Wright [mailto:hy...@hyrumwright.org] >> Sent: donderdag 14 april 2011 17:47 >> To: dev@subversion.apache.org >> Cc: rhuij...@apache.org; comm...@subversion.apache.org >> Subject: Re: svn commit: r1091928 - in /subversion/trunk/subversion: >> libsvn_client/commit.c tests/cmdline/commit_tests.py >> >> On Wed, Apr 13, 2011 at 4:47 PM, wrote: >> > Author: rhuijben >> > Date: Wed Apr 13 21:47:24 2011 >> > New Revision: 1091928 >> > >> > URL: http://svn.apache.org/viewvc?rev=1091928&view=rev >> > Log: >> > Fix issue #2381: "Cannot commit multiple WC paths which lack a common >> parent >> > directory" by making the commit processor determine which locks it needs >> in >> > which working copy. >> >> I've not looked at the code, but am just wondering about a theoretical >> point here. Could the approach fall victim to the same cause as issue >> #3242? Specifically, if all the commits are done in the same editor >> drive, and that editor drive is rooted somewhere outside of the >> readable or writable location for the user doing the commit, would we >> get authz denials? >> >> I can just envision the scenario where users try to commit multiple >> working copies rooted somewhere they can't write to, and it ends up in >> all kinds of confusion. (Just another reason to introduce the eXecute >> bit in our authz paradigm...) > > By default commit works exactly as before. It's just that you can pass > explicit targets from multiple working copies. > > Yes, that might give you issue #3242, but like Michael said you can have > that issue in any tree. > > The fact that you can now commit in multiple working copies at once, doesn't > say that it is the right thing to do: it's just an option. > (And in many cases it is NOT the right thing to do) Oh certainly. I'm not claiming we should back out this new feature, just that we should be aware of potential uncertainties that users may encounter when trying to use it. FWIW, I had similar concerns about a patch I proposed for issue #1199, and it never got applied because of them, so I'm a bit sensitive to this class of issue. The patch has long since bitrotted. :( Oh, and I also coded up the original implementation of issue #3242. (Not the fix, the implementation) -Hyrum
Inconsistent use of full stop in notifications
In upgrading an old working copy to the 1.7 format, I noticed a full stop in the message "Upgraded 'subversion/svn'.". It it grammatically correct, but feels a bit extraneous. In looking through subversion/svn/notify.c, I noticed we do use the full stop in a number of places, but in lots of places we don't. There doesn't seem to be any grammatical pattern to our use or nonuse. Unfortunately, I know just enough English grammar to be dangerous, but not productive. I don't think we should do anything about it right now (more important fish to fry and all that), but I thought I'd bring it up nonetheless. -Hyrum
RE: svn commit: r1091928 - in /subversion/trunk/subversion: libsvn_client/commit.c tests/cmdline/commit_tests.py
> -Original Message- > From: Hyrum K Wright [mailto:hy...@hyrumwright.org] > Sent: donderdag 14 april 2011 17:47 > To: dev@subversion.apache.org > Cc: rhuij...@apache.org; comm...@subversion.apache.org > Subject: Re: svn commit: r1091928 - in /subversion/trunk/subversion: > libsvn_client/commit.c tests/cmdline/commit_tests.py > > On Wed, Apr 13, 2011 at 4:47 PM, wrote: > > Author: rhuijben > > Date: Wed Apr 13 21:47:24 2011 > > New Revision: 1091928 > > > > URL: http://svn.apache.org/viewvc?rev=1091928&view=rev > > Log: > > Fix issue #2381: "Cannot commit multiple WC paths which lack a common > parent > > directory" by making the commit processor determine which locks it needs > in > > which working copy. > > I've not looked at the code, but am just wondering about a theoretical > point here. Could the approach fall victim to the same cause as issue > #3242? Specifically, if all the commits are done in the same editor > drive, and that editor drive is rooted somewhere outside of the > readable or writable location for the user doing the commit, would we > get authz denials? > > I can just envision the scenario where users try to commit multiple > working copies rooted somewhere they can't write to, and it ends up in > all kinds of confusion. (Just another reason to introduce the eXecute > bit in our authz paradigm...) By default commit works exactly as before. It's just that you can pass explicit targets from multiple working copies. Yes, that might give you issue #3242, but like Michael said you can have that issue in any tree. The fact that you can now commit in multiple working copies at once, doesn't say that it is the right thing to do: it's just an option. (And in many cases it is NOT the right thing to do) Bert
Failing ruby bindings tests
Sometime last week, the ruby bindings started failing. It happened after one of my commits to the changelist code, but I've reason to believe that's not the correct culprit. Something is happening in the set up of the test harness, and all of the errors are of the form: [[[ 164) Error: test_wc(SvnWcTest): Svn::Error::WcObstructedUpdate: subversion/libsvn_wc/adm_files.c:490: Svn::Error::WcObstructedUpdate: URL 'file:///var/lib/buildbot/svn-buildslave/svn-x64-ubuntu/build/subversion/bindings/swig/ruby/repos' doesn't match existing URL 'file:///var/lib/buildbot/svn-buildslave/svn-x64-ubuntu/build/subversion/bindings/swig/ruby/repos' in '/tmp/wc-tmp/wc' /var/lib/buildbot/svn-buildslave/svn-x64-ubuntu/build/subversion/bindings/swig/ruby/svn/util.rb:99:in `svn_client_checkout3' /var/lib/buildbot/svn-buildslave/svn-x64-ubuntu/build/subversion/bindings/swig/ruby/svn/util.rb:99:in `checkout3' /var/lib/buildbot/svn-buildslave/svn-x64-ubuntu/build/subversion/bindings/swig/ruby/svn/client.rb:143:in `checkout' /var/lib/buildbot/svn-buildslave/svn-x64-ubuntu/build/subversion/bindings/swig/ruby/test/util.rb:139:in `setup_wc' /var/lib/buildbot/svn-buildslave/svn-x64-ubuntu/build/subversion/bindings/swig/ruby/test/util.rb:202:in `make_context' /var/lib/buildbot/svn-buildslave/svn-x64-ubuntu/build/subversion/bindings/swig/ruby/test/util.rb:139:in `setup_wc' /var/lib/buildbot/svn-buildslave/svn-x64-ubuntu/build/subversion/bindings/swig/ruby/test/util.rb:61:in `setup_basic' /var/lib/buildbot/svn-buildslave/svn-x64-ubuntu/build/subversion/bindings/swig/ruby/test/test_wc.rb:32:in `setup' ]]] This doesn't look like changelists to me. :) I know there has been some work recently in recognizing obstructing nodes on update, and I'm wondering if these failures are related to that work. The two URLs that the error claims are dissimilar appear to in fact match, but digging into the code I'm not sure what should trigger the error condition, or what the appropriate response is. Any thoughts would be useful. -Hyrum
Re: svn commit: r1091928 - in /subversion/trunk/subversion: libsvn_client/commit.c tests/cmdline/commit_tests.py
On 04/14/2011 11:47 AM, Hyrum K Wright wrote: > On Wed, Apr 13, 2011 at 4:47 PM, wrote: >> Author: rhuijben >> Date: Wed Apr 13 21:47:24 2011 >> New Revision: 1091928 >> >> URL: http://svn.apache.org/viewvc?rev=1091928&view=rev >> Log: >> Fix issue #2381: "Cannot commit multiple WC paths which lack a common parent >> directory" by making the commit processor determine which locks it needs in >> which working copy. > > I've not looked at the code, but am just wondering about a theoretical > point here. Could the approach fall victim to the same cause as issue > #3242? Specifically, if all the commits are done in the same editor > drive, and that editor drive is rooted somewhere outside of the > readable or writable location for the user doing the commit, would we > get authz denials? I would expect that this could happen, yes. But the same could happen in a single working copy, too, couldn't it? I'm thinking of a sparse checkout at the root with authz like this: [repos:/] username = r [repos:/trunk] username = rw [repos:/branches] username = rw And then 'username' tries to commit to both the trunk and a branch at the same time. > (Just another reason to introduce the eXecute bit in our authz paradigm...) +1! -- C. Michael Pilato CollabNet <> www.collab.net <> Distributed Development On Demand signature.asc Description: OpenPGP digital signature
Re: Find a deleted file and WC-NG
On 04/13/2011 10:55 PM, Gavin "Beau" Baumanis wrote: > If the information is appropriately stored in the repository, and can be > resolved somewhat via doing svn log / text searches; Why can't a > function ; getTheLastRevisionAndPathThisFileExisted(filename, > repo://startingPath); be created? that does that process for me under the > hood? We have an RA function, svn_ra_get_deleted_rev(path, peg_rev, end_rev) and a corresponding repos API function svn_repos_get_deleted_rev(path, start, end) which might do what you are looking for. Maybe that could serve as at least a starting point as you investigate how to make Subversion do what you want here? -- C. Michael Pilato CollabNet <> www.collab.net <> Distributed Development On Demand signature.asc Description: OpenPGP digital signature
Why do we include debug symbols in !maintainer_mode?
I just built a version of trunk to use on my "production" working copies, and configured it without maintainer mode. I noticed that it was using '-g -O2' in the CFLAGS, which seems completely nonsensical: debug symbols often refer to stuff that gets optimized away, and just bloats the final executable. Although I don't know if this has any impact on the processor i-cache, I still don't see much reason for using '-g -O2' in non-maintainer mode. Some voice in the back of my head says we've had this discussion before, but I can't seem to find it. I just wanted to check here before I went and changed things. (And for the record, I hacked my local Makefile to remove '-g' from CFLAGS.) -Hyrum
RE: 1.7 Roadmap Items Evaluation
All of them: add, remove and change. Just check something like the merge support over 1.6.X. Bert Huijben (Cell phone) From: Blair Zajac Sent: donderdag 14 april 2011 18:06 To: Julian Foad Cc: Branko Čibej; dev@subversion.apache.org Subject: Re: 1.7 Roadmap Items Evaluation On Apr 14, 2011, at 2:19 AM, Julian Foad wrote: > Blair Zajac wrote: >> On 04/13/2011 03:17 AM, Julian Foad wrote: >>> Branko Čibej wrote: On 13.04.2011 11:37, Julian Foad wrote: > On Wed, 2011-04-13 at 11:33 +0200, Branko Čibej wrote: >> On 12.04.2011 18:50, Julian Foad wrote: >>> On Mon, 2011-04-11 at 11:08 -0400, C. Michael Pilato wrote: On 04/07/2011 08:49 PM, Daniel Shahaf wrote: > C. Michael Pilato wrote on Thu, Apr 07, 2011 at 11:19:48 -0400: >> "Remove temp APIs": I would put this at "nice to have". These APIs >> are >> private, so what's the penalty if they wind up in the release? > We'd have to support them privately for the rest of the 1.7.x line, > due > to private ABI compatibility? > > http://article.gmane.org/gmane.comp.version-control.subversion.devel/125849 Ah, okay. I didn't realize that we allowed mix-and-match of patch-level-differing-only versions. >>> Erm... AFAIK, we don't support a mis-matched set of libraries (e.g. >>> libsvn_client 1.7.0 + libsvn_wc 1.7.1 + ...), so it's fine to have >>> internal APIs that are called from a different Subversion library, and >>> we won't need to preserve those through 1.7.x. >> Then you'd better change the version checking code in the libraries. > Please correct my understanding or ... wait a sec, this is already doc'd > in 'Hacking', so I'll go take a look and correct myself. >>> >>> Are you saying we *do* support running a mixed set of Subversion >>> libraries (e.g. libsvn_client 1.7.0 + libsvn_wc 1.7.1 + ...)? I was >>> under the impression we had a policy of "you must upgrade (or downgrade) >>> the libraries as a complete set, not individually". >> >> That's my understanding too, and IIRC, we've done this in the past with > > What's "this"? Add, modify or remove private functions. Blair
Re: 1.7 Roadmap Items Evaluation
On Apr 14, 2011, at 2:19 AM, Julian Foad wrote: > Blair Zajac wrote: >> On 04/13/2011 03:17 AM, Julian Foad wrote: >>> Branko Čibej wrote: On 13.04.2011 11:37, Julian Foad wrote: > On Wed, 2011-04-13 at 11:33 +0200, Branko Čibej wrote: >> On 12.04.2011 18:50, Julian Foad wrote: >>> On Mon, 2011-04-11 at 11:08 -0400, C. Michael Pilato wrote: On 04/07/2011 08:49 PM, Daniel Shahaf wrote: > C. Michael Pilato wrote on Thu, Apr 07, 2011 at 11:19:48 -0400: >> "Remove temp APIs": I would put this at "nice to have". These APIs >> are >> private, so what's the penalty if they wind up in the release? > We'd have to support them privately for the rest of the 1.7.x line, > due > to private ABI compatibility? > > http://article.gmane.org/gmane.comp.version-control.subversion.devel/125849 Ah, okay. I didn't realize that we allowed mix-and-match of patch-level-differing-only versions. >>> Erm... AFAIK, we don't support a mis-matched set of libraries (e.g. >>> libsvn_client 1.7.0 + libsvn_wc 1.7.1 + ...), so it's fine to have >>> internal APIs that are called from a different Subversion library, and >>> we won't need to preserve those through 1.7.x. >> Then you'd better change the version checking code in the libraries. > Please correct my understanding or ... wait a sec, this is already doc'd > in 'Hacking', so I'll go take a look and correct myself. >>> >>> Are you saying we *do* support running a mixed set of Subversion >>> libraries (e.g. libsvn_client 1.7.0 + libsvn_wc 1.7.1 + ...)? I was >>> under the impression we had a policy of "you must upgrade (or downgrade) >>> the libraries as a complete set, not individually". >> >> That's my understanding too, and IIRC, we've done this in the past with > > What's "this"? Add, modify or remove private functions. Blair
Re: svn commit: r1091928 - in /subversion/trunk/subversion: libsvn_client/commit.c tests/cmdline/commit_tests.py
On Wed, Apr 13, 2011 at 4:47 PM, wrote: > Author: rhuijben > Date: Wed Apr 13 21:47:24 2011 > New Revision: 1091928 > > URL: http://svn.apache.org/viewvc?rev=1091928&view=rev > Log: > Fix issue #2381: "Cannot commit multiple WC paths which lack a common parent > directory" by making the commit processor determine which locks it needs in > which working copy. I've not looked at the code, but am just wondering about a theoretical point here. Could the approach fall victim to the same cause as issue #3242? Specifically, if all the commits are done in the same editor drive, and that editor drive is rooted somewhere outside of the readable or writable location for the user doing the commit, would we get authz denials? I can just envision the scenario where users try to commit multiple working copies rooted somewhere they can't write to, and it ends up in all kinds of confusion. (Just another reason to introduce the eXecute bit in our authz paradigm...) -Hyrum
Re: svn commit: r1092047 - in /subversion/trunk: Makefile.in subversion/tests/cmdline/davautocheck.sh
On Thu, 14 Apr 2011 10:38 -0400, "C. Michael Pilato" wrote: > On 04/14/2011 09:20 AM, Daniel Shahaf wrote: > > On Thu, 14 Apr 2011 08:59 -0400, "C. Michael Pilato" > > wrote: > >> On 04/14/2011 04:17 AM, danie...@apache.org wrote: > >>> URL: http://svn.apache.org/viewvc?rev=1092047&view=rev > >>> Log: > >>> Allow running davautocheck with HTTPv2 disabled. > >> > >> I *think* you could probably have done this already by setting > >> SVN_I_LIKE_LATENCY_SO_IGNORE_HTTPV2=yes in the environment before kicking > >> off the 'make davautocheck'. > >> > > > > That's a different beast --- it's a client-side, not server-side, directive. > > True, but it's effectively the same result. The server-side directive > doesn't turn off HTTPv2 support -- only the server's advertisement > thereof. Ah, I didn't realize that. I agree then that there would be little difference between disabling httpv2 in the client or in the server. > The client-side envvar hack tells the client to ignore the > advertisement if it comes.
Re: svn commit: r1092047 - in /subversion/trunk: Makefile.in subversion/tests/cmdline/davautocheck.sh
On 04/14/2011 09:20 AM, Daniel Shahaf wrote: > On Thu, 14 Apr 2011 08:59 -0400, "C. Michael Pilato" > wrote: >> On 04/14/2011 04:17 AM, danie...@apache.org wrote: >>> URL: http://svn.apache.org/viewvc?rev=1092047&view=rev >>> Log: >>> Allow running davautocheck with HTTPv2 disabled. >> >> I *think* you could probably have done this already by setting >> SVN_I_LIKE_LATENCY_SO_IGNORE_HTTPV2=yes in the environment before kicking >> off the 'make davautocheck'. >> > > That's a different beast --- it's a client-side, not server-side, directive. True, but it's effectively the same result. The server-side directive doesn't turn off HTTPv2 support -- only the server's advertisement thereof. The client-side envvar hack tells the client to ignore the advertisement if it comes. -- C. Michael Pilato CollabNet <> www.collab.net <> Distributed Development On Demand signature.asc Description: OpenPGP digital signature
[svnbench] Revision: 1091976 compiled Apr 14 2011, 00:21:28
Hi all, yesterday's and today's benchmarks look particularly good (listed below). I haven't paid attention to commits, but it seems some pretty good perf commits have happened recently (except for 'svn delete'). 'svn delete' is still 10 times slower on trunk for 100x1 (in a deep working copy of 100 nested dirs and a file each), and 20 times slower for 5x5 (tree of 5 levels and 5 subtrees per node). In all the other cases and all the other svn commands, trunk seems either faster, *much* faster, or roughly the same speed. There are a few ratings showing a slower trunk, but these account mostly for delays in hundredth seconds range. Compared to the timings I saw 6 months ago, this looks really really really good!! :D I just verified these results on the hardware I originally tested on (the benchmarks you are seeing these days are run on our ASF VM). On my "old" laptop, the ratings show less speed gain for trunk than on the VM (mostly no speed gain, really), but results confirm the same tendency: the speed factors, except for 'svn delete', are mostly close to 1 -- and used to be a lot higher. Again, an exception: on my old hardware, 'svn merge' still slows down on trunk. But Remarkably, 'merge' used to be around factors 2.6 and higher (= trunk much slower), which has gone down to only around 1.4. On all hardware, 'svn delete', in situations with multiple dir levels, has gone Evil since the benchmarks a few months ago. So, to summarize, runtime wise we are on par with 1.6.x with exceptions: - Someone broke/had to break 'svn delete'-with-multiple-dir-levels perf. Trunk can take 10 and 20 times longer here, which seems a bit off. - On some hardware, 'svn merge' is slower on trunk, but... ...it's not as bad as a few months ago and ...on our VM, 'merge' is actually not slower but faster on trunk and ...remember that this is measuring mostly libsvn_wc overhead because benchmarks use ra_local only, and my guess is that merge over http slows down such that this should become hardly noticeable. - I also see that trunk seems to be able to better put high-performance hardware to use than 1.6 did, since on our VM I see noticeable perf improvements, which doesn't show on "normal" hardware. - Almost forgot to mention: 'svn status' is slower on trunk (5x5 case). Though this accounts for only + half-a-second on average, IMHO it would be nice for 'svn status' to be as fast as possible. All in all, once we clarified why 'svn delete' is as slow (and possibly choose not to worry about it), I'd suggest that trunk's performance is release worthy when compared to 1.6.x. The best numbers are the "TOTAL RUN" ones, where the whole test run is summed up; with the numbers shown here, we can statistically prove that, hold your breath, ~ --- Trunk Is Faster Than 1.6.x (*)--- ~ (*) Yay! Hmm, stsp, wouldn't that also make a good T-shirt slogan? ;) ~Neels Results for dir levels: 5 spread: 5 5x5 with 1.6: ~444 seconds trunk: ~418 seconds COMPARE 5x5_1.6 to 5x5_trunk 1.23|+0.45 means factor=1.23, difference in seconds = 0.45 factor < 1 or difference < 0 means '5x5_trunk' is faster than '5x5_1.6' min max avg operation 0.88|-47.746 0.95|-25.249 0.94|-25.663 TOTAL RUN 1.29| +0.002 0.48| -4.468 0.86| -0.006 add 1.73| +0.010 0.54| -6.573 0.55| -2.626 checkout 0.64| -2.009 0.51|-28.064 0.67| -6.072 commit 0.65| -0.014 0.09| -0.621 0.22| -0.157 copy 40.04|+92.02110.96|+116.441 19.45|+102.098 delete 1.09| +0.678 0.46|-17.970 0.74| -3.778 merge 1.38| +0.003 0.60| -0.090 1.53| +0.006 mkdir 1.23| +0.002 0.06| -3.518 0.84| -0.003 prop mod 1.18| +0.002 0.03| -2.268 0.32| -0.032 propdel 1.21| +0.002 0.07| -1.481 1.38| +0.004 proplist 1.24| +0.002 0.08| -5.684 0.86| -0.003 propset 1.18| +0.002 1.89| +0.031 1.50| +0.006 resolve 3.02| +0.615 1.16| +0.279 2.24| +0.836 resolved 1.39| +0.070 0.74| -1.075 1.78| +0.420 status 0.52| -4.281 0.35|-14.527 0.40| -8.079 switch 1.61| +0.092 0.24|-27.006 0.40| -3.899 update Results for dir levels: 100 spread: 1 100x1 with 1.6: ~78 seconds trunk: ~28 seconds (!) COMPARE 100x1_1.6 to 100x1_trunk 1.23|+0.45 means factor=1.23, difference in seconds = 0.45 factor < 1 or difference < 0 means '100x1_trunk' is faster than '100x1_1.6' min max avg operation 0.35|-47.448 0.36|-53.207 0.36|-49.989 TOTAL RUN 1.26| +0.002 0.42| -0.435 0.76| -0.008 add 1.73| +0.009 0.06| -7.794 0.07| -3.062 checkout 0.44| -0.408 0.85| -0.400 0.81| -0.224 commit 0.87| -0.003 0.18| -0.134 0.
Re: svn commit: r1092047 - in /subversion/trunk: Makefile.in subversion/tests/cmdline/davautocheck.sh
On Thu, 14 Apr 2011 08:59 -0400, "C. Michael Pilato" wrote: > On 04/14/2011 04:17 AM, danie...@apache.org wrote: > > URL: http://svn.apache.org/viewvc?rev=1092047&view=rev > > Log: > > Allow running davautocheck with HTTPv2 disabled. > > I *think* you could probably have done this already by setting > SVN_I_LIKE_LATENCY_SO_IGNORE_HTTPV2=yes in the environment before kicking > off the 'make davautocheck'. > That's a different beast --- it's a client-side, not server-side, directive. Thanks for the tip though, I've add a placeholder in notes/knobs for it.
Re: svn commit: r1092047 - in /subversion/trunk: Makefile.in subversion/tests/cmdline/davautocheck.sh
On 04/14/2011 04:17 AM, danie...@apache.org wrote: > Author: danielsh > Date: Thu Apr 14 08:17:40 2011 > New Revision: 1092047 > > URL: http://svn.apache.org/viewvc?rev=1092047&view=rev > Log: > Allow running davautocheck with HTTPv2 disabled. I *think* you could probably have done this already by setting SVN_I_LIKE_LATENCY_SO_IGNORE_HTTPV2=yes in the environment before kicking off the 'make davautocheck'. -- C. Michael Pilato CollabNet <> www.collab.net <> Distributed Development On Demand signature.asc Description: OpenPGP digital signature
Re: 1.7 Roadmap Items Evaluation
Blair Zajac wrote: > On 04/13/2011 03:17 AM, Julian Foad wrote: > > Branko Čibej wrote: > >> On 13.04.2011 11:37, Julian Foad wrote: > >>> On Wed, 2011-04-13 at 11:33 +0200, Branko Čibej wrote: > On 12.04.2011 18:50, Julian Foad wrote: > > On Mon, 2011-04-11 at 11:08 -0400, C. Michael Pilato wrote: > >> On 04/07/2011 08:49 PM, Daniel Shahaf wrote: > >>> C. Michael Pilato wrote on Thu, Apr 07, 2011 at 11:19:48 -0400: > "Remove temp APIs": I would put this at "nice to have". These APIs > are > private, so what's the penalty if they wind up in the release? > >>> We'd have to support them privately for the rest of the 1.7.x line, > >>> due > >>> to private ABI compatibility? > >>> > >>> http://article.gmane.org/gmane.comp.version-control.subversion.devel/125849 > >> Ah, okay. I didn't realize that we allowed mix-and-match of > >> patch-level-differing-only versions. > > Erm... AFAIK, we don't support a mis-matched set of libraries (e.g. > > libsvn_client 1.7.0 + libsvn_wc 1.7.1 + ...), so it's fine to have > > internal APIs that are called from a different Subversion library, and > > we won't need to preserve those through 1.7.x. > Then you'd better change the version checking code in the libraries. > >>> Please correct my understanding or ... wait a sec, this is already doc'd > >>> in 'Hacking', so I'll go take a look and correct myself. > > > > Are you saying we *do* support running a mixed set of Subversion > > libraries (e.g. libsvn_client 1.7.0 + libsvn_wc 1.7.1 + ...)? I was > > under the impression we had a policy of "you must upgrade (or downgrade) > > the libraries as a complete set, not individually". > > That's my understanding too, and IIRC, we've done this in the past with What's "this"? > merges to release branches. - Julian
RE: svn up problem using latest trunk revision (1092011)
Indeed, r1092033 fixes the problem to.
Thanks,
Marc
-Original Message-
From: Bert Huijben [mailto:b...@qqmail.nl]
Sent: donderdag 14 april 2011 9:49
To: Marc Haesen; dev@subversion.apache.org
Subject: RE: svn up problem using latest trunk revision (1092011)
> -Original Message-
> From: Bert Huijben [mailto:b...@qqmail.nl]
> Sent: donderdag 14 april 2011 9:19
> To: 'Marc Haesen'; dev@subversion.apache.org
> Subject: RE: svn up problem using latest trunk revision (1092011)
> This patch would only affect the error:
>
> if (recorded_base_checksum && expected_base_checksum
> && strcmp(expected_base_checksum, recorded_base_checksum) !=
0)
> return svn_error_createf(SVN_ERR_WC_CORRUPT_TEXT_BASE, NULL,
> _("Checksum mismatch for '%s':\n"
>" expected: %s\n"
>" recorded: %s\n"),
> svn_dirent_local_style(fb->local_abspath, pool),
> expected_base_checksum, recorded_base_checksum);
>
> While you got the error from a different function.
>
> Are you sure you tested this on a clean checkout?
>
> (What HEAD version did you get on the checkout? I can't reproduce it
here)
While I couldn't reproduce this issue, I expect that it is fixed by
r1092033.
(In a different way than in your patch: It uses SHA1 properly when the
server doesn't provide a checksum)
Bert
RE: svn up problem using latest trunk revision (1092011)
> -Original Message-
> From: Bert Huijben [mailto:b...@qqmail.nl]
> Sent: donderdag 14 april 2011 9:19
> To: 'Marc Haesen'; dev@subversion.apache.org
> Subject: RE: svn up problem using latest trunk revision (1092011)
> This patch would only affect the error:
>
> if (recorded_base_checksum && expected_base_checksum
> && strcmp(expected_base_checksum, recorded_base_checksum) != 0)
> return svn_error_createf(SVN_ERR_WC_CORRUPT_TEXT_BASE, NULL,
> _("Checksum mismatch for '%s':\n"
>" expected: %s\n"
>" recorded: %s\n"),
> svn_dirent_local_style(fb->local_abspath, pool),
> expected_base_checksum, recorded_base_checksum);
>
> While you got the error from a different function.
>
> Are you sure you tested this on a clean checkout?
>
> (What HEAD version did you get on the checkout? I can't reproduce it here)
While I couldn't reproduce this issue, I expect that it is fixed by
r1092033.
(In a different way than in your patch: It uses SHA1 properly when the
server doesn't provide a checksum)
Bert
RE: svn up problem using latest trunk revision (1092011)
Yes, I started from an empty directory. On the initial checkout I get
revision 5538
I have the same problem on a linux version (1091675) compiled on debian.
Here is the complete output:
mahae@linux-nagios:~/temp$ svn co
http://tinyos-main.googlecode.com/svn/trunk/tos/chips/atm128/spi .
AAtm128Spi.nc
AAtm128SpiP.nc
Asim
Asim/Atm128SpiC.nc
AAtm128SpiC.nc
AHplAtm128SpiP.nc
AAtm128Spi.h
AHplAtm128SpiC.nc
Checked out revision 5538.
mahae@linux-nagios:~/temp$ svn up -r5516 .
Updating '.' ...
svn: E155017: Checksum mismatch while updating
'/home/mahae/temp/HplAtm128SpiP.nc':
expected: 95f9d9ccfd75a2e9764c2f2d4904152a
actual: 57bf0651502cd65d9446e2f44f661526
With the patch applied, everything seems to work fine and the svn up
-r5516 is giving the expected result.
Regards,
Marc
-Original Message-
From: Bert Huijben [mailto:b...@qqmail.nl]
Sent: donderdag 14 april 2011 9:19
To: Marc Haesen; dev@subversion.apache.org
Subject: RE: svn up problem using latest trunk revision (1092011)
> -Original Message-
> From: Marc Haesen [mailto:marc.hae...@oneaccess-net.com]
> Sent: donderdag 14 april 2011 8:11
> To: dev@subversion.apache.org
> Subject: svn up problem using latest trunk revision (1092011)
>
> I am using the latest version of svn on trunk compiled for windows.
When
> executing the following commands:
>
>
>
> svn co
http://tinyos-main.googlecode.com/svn/trunk/tos/chips/atm128/spi
> .
>
> svn up -r5516 .
>
>
>
> I get the following error:
>
>
>
> Updating '.' ...
>
> svn: E155017: Checksum mismatch while updating
> 'D:\temp\temp\HplAtm128SpiP.nc':
>
>expected: 95f9d9ccfd75a2e9764c2f2d4904152a
>
> actual: 57bf0651502cd65d9446e2f44f661526
This patch would only affect the error:
if (recorded_base_checksum && expected_base_checksum
&& strcmp(expected_base_checksum, recorded_base_checksum) != 0)
return svn_error_createf(SVN_ERR_WC_CORRUPT_TEXT_BASE, NULL,
_("Checksum mismatch for '%s':\n"
" expected: %s\n"
" recorded: %s\n"),
svn_dirent_local_style(fb->local_abspath, pool),
expected_base_checksum, recorded_base_checksum);
While you got the error from a different function.
Are you sure you tested this on a clean checkout?
(What HEAD version did you get on the checkout? I can't reproduce it
here)
Bert
RE: svn up problem using latest trunk revision (1092011)
> -Original Message-
> From: Marc Haesen [mailto:marc.hae...@oneaccess-net.com]
> Sent: donderdag 14 april 2011 8:11
> To: dev@subversion.apache.org
> Subject: svn up problem using latest trunk revision (1092011)
>
> I am using the latest version of svn on trunk compiled for windows. When
> executing the following commands:
>
>
>
> svn co http://tinyos-main.googlecode.com/svn/trunk/tos/chips/atm128/spi
> .
>
> svn up -r5516 .
>
>
>
> I get the following error:
>
>
>
> Updating '.' ...
>
> svn: E155017: Checksum mismatch while updating
> 'D:\temp\temp\HplAtm128SpiP.nc':
>
>expected: 95f9d9ccfd75a2e9764c2f2d4904152a
>
> actual: 57bf0651502cd65d9446e2f44f661526
This patch would only affect the error:
if (recorded_base_checksum && expected_base_checksum
&& strcmp(expected_base_checksum, recorded_base_checksum) != 0)
return svn_error_createf(SVN_ERR_WC_CORRUPT_TEXT_BASE, NULL,
_("Checksum mismatch for '%s':\n"
" expected: %s\n"
" recorded: %s\n"),
svn_dirent_local_style(fb->local_abspath, pool),
expected_base_checksum, recorded_base_checksum);
While you got the error from a different function.
Are you sure you tested this on a clean checkout?
(What HEAD version did you get on the checkout? I can't reproduce it here)
Bert
