Re: svnlook_tests.py 12 failing on trunk and 1.6.x over ra_serf and ra_neon
What? I thought svnlook was purely a server-side tool. What does the RA layer have to do with it? On Thu, Apr 8, 2010 at 21:34, Paul Burba wrote: > As I mentioned in IRC earlier this week, svnlook_tests.py 12 was > failing for me on Windows over ra_neon and ra_serf (svnlook_tests.py > 11 on the 1.6.x branch). > > The test failed when the python pre-commit hook failed to write the > output of 'svnlook -t' to a temporary file. Thing is, breaking a > debug mid-way through the tests' commit so the transaction file was > still present, and running svnlook from the command line worked fine. > Heck, even running the hook script from the command line worked. > > At first I thought that only a release build of Apache was > susceptible; running the tests again a debug version of httpd.exe > worked fine. Somewhat belatedly I tried running against a manually > started release build of httpd.exe and damn if it didn't work too. > > So it seems something is amiss with my Apache InstallBin target, > though what I'm not yet sure (and honestly won't be spending any more > time trying to figure out unless someone else has the same problem). > > Anyhow, I mention all of this because for me it would have blocked > 1.6.11, but all is good now. > > Paul >
Re: Subversion Vision and Roadmap Proposal
On Thu, Apr 8, 2010 at 22:55, Tim Starling wrote: > C. Michael Pilato wrote: >> We need to find a way to embrace and >> empower would-be Subversion contributors. > > You could start by replying to their mailing list posts. Just a thought. Well aware of that, and snarky behavior won't really endear you to anybody. In particular, there are people who have patches for svn, and we don't handle them very well. In some cases, there is a high bar of review/change/resubmit that turns people off. In other cases, people are focused on whatever task they're working on, and the patches are left by the wayside. We have a Patch Manager that attempts to ensure we don't completely lose patches, but that is a far cry from *engaging* those patch developers. In other scenarios, we have several people all providing "input" and "direction" to the would-be patch-provider. That incoherency and pulls in different directions can also turn off potential contributors. We talked about these issues, and how we could provide "mentors" to work with people that arrive with patches. A person would be volunteer to work with the patcher, and provide a single point of contact/review. Of course, do we have enough people willing and able to fill that role? (if that is even the best way!) Cheers, -g
Re: Subversion Vision and Roadmap Proposal
C. Michael Pilato wrote: > We need to find a way to embrace and > empower would-be Subversion contributors. You could start by replying to their mailing list posts. Just a thought. -- Tim Starling
svnlook_tests.py 12 failing on trunk and 1.6.x over ra_serf and ra_neon
As I mentioned in IRC earlier this week, svnlook_tests.py 12 was failing for me on Windows over ra_neon and ra_serf (svnlook_tests.py 11 on the 1.6.x branch). The test failed when the python pre-commit hook failed to write the output of 'svnlook -t' to a temporary file. Thing is, breaking a debug mid-way through the tests' commit so the transaction file was still present, and running svnlook from the command line worked fine. Heck, even running the hook script from the command line worked. At first I thought that only a release build of Apache was susceptible; running the tests again a debug version of httpd.exe worked fine. Somewhat belatedly I tried running against a manually started release build of httpd.exe and damn if it didn't work too. So it seems something is amiss with my Apache InstallBin target, though what I'm not yet sure (and honestly won't be spending any more time trying to figure out unless someone else has the same problem). Anyhow, I mention all of this because for me it would have blocked 1.6.11, but all is good now. Paul
Growing developer community (was Subversion Vision and Roadmap Proposal)
On Fri, Apr 2, 2010 at 5:28 PM, C. Michael Pilato wrote:
[...]
> COMMUNITY
> [...]
>
> But communication alone isn't enough. We need to find ways to grow our
> developer community itself. Attendance at the recent Subversion Corporation
> Annual Members Meeting was low (by design and recommendation, of course),
> but a startling realization was made there. When the agenda item for voting
> new full committers into membership was on the table, there were no
> candidates. Think about that: no new full committers for Subversion in the
> past year. This is a bad thing. We need to find a way to embrace and
> empower would-be Subversion contributors. Telling them to troll through the
> issue tracker looking for bite-sized issues is not the way to do that -- it
> communicates "we can't be bothered to mentor you". When somebody wants to
> start making contributions, our community must recognize the value of that
> contributor and mentor him or her toward full committership, for the good of
> that contributor and of the community. Further, our public roadmap needs to
> highlight the items that we really wish we could be working on but lack the
> manpower to handle. This would provide those looking for ways to accelerate
> Subversion's roadmap with some cues for doing that in harmony with the Big
> Picture.
FWIW, I just wanted to add my view on this, as a relative newcomer to
svn (using & administering since 1 year, and becoming more and more of
an enthusiast).
Being a software developer myself (ok, my C knowledge/experience is
pretty limited and somewhat rusty, but whatever) I've been trying for
a while to become more involved, looking around for something I could
contribute in the form of code (like [1]).
IMHO a couple of things made it unnecessarily difficult to make the
transition from enthusiast to feeling confident enough to dive into
the code:
1) Subversion Community Guide (aka HACKING): it may be a great
reference and important guideline to keep everyone in line, but it's
not very good for getting new developers started.
* It's huge, so it takes a lot of time to read and understand.
* The document indicates that you have to read through the entire
document before considering to contribute code ("No, wait, first read
the rest of this file, then start sending patches to
d...@subversion.apache.org. :-)").
* It's not only the document itself, but also the stuff it refers to
(in "Theory and documentation" and in "Code to read"). For people like
me (the sensing type, for people that know MBTI :-)), that means I
*have to* grok all that stuff before I can move on.
* It contains a lot of stuff that's not really that important for
someone trying to make a first contribution
Don't get me wrong: all the stuff in there is very important, and so
is the documentation it references (it helped me a lot to understand
the code), but it is a lot. It might be easier, more efficient, ...
for people considering to make their first contribution to make some
kind of "bootstrap document" out of it, and let people dive into the
code as quickly as possible.
2) Missing medium-level documentation. I'm missing something in
between the old design spec (although outdated, it's still quite
useful; however, it should really be updated) and the documentation in
the code. The code is very well documented, but as a newcomer I found
it quite difficult to get a grasp on the larger structures, flow, how
things are interconnected (layers, callbacks, ...), ... Maybe
something in between the high level design doc and the
code-documentation could help?
3) It's too difficult to get a development/debugging/testing
environment up and running, especially on Windows. That was really a
huge time sink for me ...
Just my 2 cents ...
--
Johan
[1] http://svn.haxx.se/dev/archive-2010-03/0503.shtml - Looking to
improve performance of svn annotate
deprecate all of svn_wc.h ?
Hey all, It has come up a few times on IRC discussions: "we should never have exposed libsvn_wc, just libsvn_client". Well, we've already exposed it, so we need to at least keep that stuff around. But moving forward... should new functions continue to be exposed? Or should all new functions go into svn_wc_private.h? This question is (probably) directed at our (GUI) client developers. Do you ever use WC functions? And if you do, then which ones? Where is svn_client.h insufficient, leading you to use svn_wc.h APIs? Note: I think the separation is a Good Thing, for our benefit, but we don't necessarily have to expose the WC layer to downstream developers. Cheers, -g
Re: Properties (was Re: Subversion Vision and Roadmap Proposal)
On Thu, Apr 8, 2010 at 15:35, C. Michael Pilato wrote: > Martin Hauner wrote: >> Hi, >> >> On 06.04.10 00:01, Stefan Sperling wrote: >>> On Mon, Apr 05, 2010 at 07:28:57PM +0200, Martin Hauner wrote: [..] With svn:mergeinfo I have to update after each commit because its on my root folder and always is out of date on the next commit. >>> >>> The out-of-dateness really comes from the mixed-revision working >>> copy concept, not from mergeinfo. >>> >>> The root of your working copy is not out of date right after >>> the commit. It is at the HEAD revision after commit: >>> >>> $ ls >>> alpha beta epsilon/ gamma/ >>> $ svn merge ^/trunk >>> --- Merging r2 through r4 into '.': >>> U alpha >>> --- Recording mergeinfo for merge of r2 through r4 into '.': >>> U . >>> $ svn ci -m merge >>> Sending . >>> Sending alpha >>> Transmitting file data . >>> Committed revision 5. >>> $ svn info . | grep ^Rev >>> Revision: 5 >>> >>> Maybe you do not commit the mergeinfo which is set on the root of your >>> working copy? If so, why not? >> >> I always commit merges on the root. >> >> I have tried to create an example, but it works in my test repository. I >> can't reproduce my "at work" behavior. >> >> It still complains that '.' is out of date most os the at work. And I'm >> 100% sure that it started when subversion went merge-tracking. > > Subversion has always disallowed commits of propchanges on a directory > that's not fully up to date. Why? For the simple reason that, after the > commit happens, that directory cannot be considered "at the new revision X" > because we never got the changes we were missing from the server. > > What happened with merge tracking is that propchanges on directories > suddenly became quite a bit more common. Like ... after every merge. If there are no propchanges on the directory in the interim, then why not allow the commit? IOW, did we disallow because we were lazy, or is there a fundamental problem with allowing the commit to proceed? Cheers, -g
Re: Subversion Vision and Roadmap Proposal
Hey - +1! I'm a game developer. I don't claim to have more insight that you guys do, but reading about the Subversion vision on LWN prompted me to post to the comment, but really I should echo that here. There is a case for centralized RCS, and I think it becomes stronger as repositories scale up. A lot. I've included my text here, and a link to the post. Thanks, Jools http://lwn.net/Articles/382780/ re: Support large repositories! Yes! Rightly or wrongly game developers have large repositories, with lots of binary files in them. For instance here's the sizes of repository I'm working with. * Accurev: 22GB workspace in 130,000 files on disk, history going back to 2003, * Perforce: 115GB workspace in 50,000 files on disk, a couple of years of history Both of these systems are well able to cope with this. For Subversion, as a centralised VCS, this is the competition. For what it's worth these are the advantages which being centralised can bring IMO: * nothing but the files locally. at those sizes you don't want to have to have the whole repository locally (optionally would be fine!), or the pristine copy that subversion currently keeps. * central backup * central access to all commited code on all branches Being centralised shouldn't stop the painless branching and merging that DVCS has. I've used Accurev a lot, and IMO it's competitive with Mercurial for this, although the command line is clunkier. (Use the GUI!) OTOH a DVCS could bring all of the features above. As far as I know right now nothing does :( I'd love to be proved wrong on this! Those sizes of repository also suggest why some systems e.g. Perforce use the checkout-before-edit system: it greatly reduces the file scanning required, and so speeds up some client operations greatly.
Re: Properties (was Re: Subversion Vision and Roadmap Proposal)
Martin Hauner wrote: > Hi, > > On 06.04.10 00:01, Stefan Sperling wrote: >> On Mon, Apr 05, 2010 at 07:28:57PM +0200, Martin Hauner wrote: >>> [..] >>> With svn:mergeinfo I have to update after each commit because its on >>> my root folder and always is out of date on the next commit. >> >> The out-of-dateness really comes from the mixed-revision working >> copy concept, not from mergeinfo. >> >> The root of your working copy is not out of date right after >> the commit. It is at the HEAD revision after commit: >> >> $ ls >> alphabeta epsilon/ gamma/ >> $ svn merge ^/trunk >> --- Merging r2 through r4 into '.': >> Ualpha >> --- Recording mergeinfo for merge of r2 through r4 into '.': >> U . >> $ svn ci -m merge >> Sending. >> Sendingalpha >> Transmitting file data . >> Committed revision 5. >> $ svn info . | grep ^Rev >> Revision: 5 >> >> Maybe you do not commit the mergeinfo which is set on the root of your >> working copy? If so, why not? > > I always commit merges on the root. > > I have tried to create an example, but it works in my test repository. I > can't reproduce my "at work" behavior. > > It still complains that '.' is out of date most os the at work. And I'm > 100% sure that it started when subversion went merge-tracking. Subversion has always disallowed commits of propchanges on a directory that's not fully up to date. Why? For the simple reason that, after the commit happens, that directory cannot be considered "at the new revision X" because we never got the changes we were missing from the server. What happened with merge tracking is that propchanges on directories suddenly became quite a bit more common. Like ... after every merge. -- C. Michael Pilato CollabNet <> www.collab.net <> Distributed Development On Demand signature.asc Description: OpenPGP digital signature
Re: Properties (was Re: Subversion Vision and Roadmap Proposal)
Hi, On 06.04.10 00:01, Stefan Sperling wrote: On Mon, Apr 05, 2010 at 07:28:57PM +0200, Martin Hauner wrote: [..] With svn:mergeinfo I have to update after each commit because its on my root folder and always is out of date on the next commit. The out-of-dateness really comes from the mixed-revision working copy concept, not from mergeinfo. The root of your working copy is not out of date right after the commit. It is at the HEAD revision after commit: $ ls alphabeta epsilon/ gamma/ $ svn merge ^/trunk --- Merging r2 through r4 into '.': Ualpha --- Recording mergeinfo for merge of r2 through r4 into '.': U . $ svn ci -m merge Sending. Sendingalpha Transmitting file data . Committed revision 5. $ svn info . | grep ^Rev Revision: 5 Maybe you do not commit the mergeinfo which is set on the root of your working copy? If so, why not? I always commit merges on the root. I have tried to create an example, but it works in my test repository. I can't reproduce my "at work" behavior. It still complains that '.' is out of date most os the at work. And I'm 100% sure that it started when subversion went merge-tracking. I'm heavily confused now. ;-) > [..] We can however improve performance (and we're already working on that). So let's assume for a moment that update took 1 nanosecond. Would that increase your productivity in an acceptable way, or would you still be put off by the fact that you need to run update after commit? And is this a big enough problem for your work flow that would make you switch to something else for version control? If it runs fast enough I personally can live with it. No system is perfect :-) I will not change the system as long as there is nothing that's a lot better than subversion. Moving from sourcs safe to cvs and from cvs to svn were big improvements. But I don't think switching from svn to something else pays off at the moment. I don't see anything that is way better for what we do at work. Thanks, Stefan -- Martin Subcommander 2.0.0 Beta 5 - http://subcommander.tigris.org a Win32/Unix/MacOSX subversion GUI client & diff/merge tool.
RE: [PATCH] Fix for issue 2753 "SVNListParentPath feature doesn't work when svn authz is used."
Thanks for the review Philip.
>Let me see if I understand: The issue is that when SVNListParentPath
>and AuthzSVNAccessFile are configured then GET requests for the parent
>path get passed through the authz stuff. This is a bug because the
>authz file doesn't control parent path.
>Your patch recognises this request and avoids doing the authz check.
Yes, exactly.
>> + canonicalized_uri = svn_uri_canonicalize(r->uri, r->pool);
>> + canonicalized_root_path = svn_uri_canonicalize(conf->base_path, r->pool);
>Can conf->base_path be canonicalised once in
>create_authz_svn_dir_config rather than for every request?
Yes should be, Will update my patch to handle this.
>> + if (strcmp(canonicalized_uri, canonicalized_root_path) == 0)
>> +{
>> + /*Do no access control when root_path(as configured in )
>> and
>> + given uri are same.*/
>> + return OK;
>> +}
>What happens if SVNParentPath is not being used? Is base_path is the
>root of the repository? Does this disable authz on the root of that
>repository? Perhaps you should be checking dav_svn__get_list_parentpath?
I tested this
$svn co http://localhost/svn <-- Repo itself instead of parent of repositories.
$cd svn
$svn ps 'a' 'b' .
$svn ci -m "commit" <-This worked as per the authz rules. Anyway will do the
directory/file creations to check in case!.
>I think this check would make more sense in access_checker rather than
>req_check_access.
Let me see and do if needed.
>The code needs a comment to say why no access control is neccessary in
>this case.
Will update the comment.
With regards
Kamesh Jayachandran
Re: svn commit: r919416 - in /subversion/trunk/subversion: include/private/ libsvn_client/ libsvn_wc/ tests/cmdline/
Greg Stein wrote: > I'm investigating some problems around file externals, and ran into > this revision. Greg, I've had plenty of time to look into file externals, too, so if you wanna compare notes... -- C. Michael Pilato CollabNet <> www.collab.net <> Distributed Development On Demand signature.asc Description: OpenPGP digital signature
Re: svn commit: r931559 - in /subversion/trunk/subversion: include/svn_fs.h libsvn_fs_base/fs.c libsvn_fs_fs/fs_fs.c svnadmin/main.c
Greg Stein wrote: > On Wed, Apr 7, 2010 at 10:08, wrote: >> Author: cmpilato >> Date: Wed Apr 7 14:08:12 2010 >> New Revision: 931559 >> >> URL: http://svn.apache.org/viewvc?rev=931559&view=rev >> Log: >> Add a --pre-1.7-compatible option to 'svnadmin create', with support >> for such in the repository and filesystem layers. > > Isn't this a misnomer? That flag makes it compatible with 1.6, and ONLY 1.6. No, a 1.6 repository is still compatible with 1.7 (and 1.8, and 1.9...). -- C. Michael Pilato CollabNet <> www.collab.net <> Distributed Development On Demand signature.asc Description: OpenPGP digital signature
Re: wc-ng base/working nodes in a copied tree
On Thu, Apr 8, 2010 at 05:53, Philip Martin wrote: > Greg Stein writes: > >> Okay. So I guess we continue to mark that as sched-delete. > > sched-delete is what we can do in 1.6, but it's not perfect. This is > not a normal delete by the user it's more of an internal Subversion > delete. One of the big differences is that the user cannot revert the > delete, because the information about the node is not available. > wc-ng could distinguish this from a normal delete. We could distinguish it in some way, yes. At a minimum, we can mark the node excluded when the user reverts the "deletion". (today, 1.6 fails, as I recall) Cheers, -g
Re: svn commit: r931918 - /subversion/trunk/subversion/libsvn_client/merge.c
On Thu, Apr 8, 2010 at 08:56, wrote: >... > +++ subversion/trunk/subversion/libsvn_client/merge.c Thu Apr 8 12:56:16 2010 >... > @@ -9540,47 +9539,44 @@ svn_client_merge_reintegrate(const char > svn_boolean_t use_sleep = FALSE; > svn_error_t *err; > struct get_subtree_mergeinfo_walk_baton wb; > - const char *target_abspath; > const char *target_url; > svn_revnum_t target_base_rev; > > - SVN_ERR(svn_dirent_get_absolute(&target_abspath, target_wcpath, pool)); > - > - /* Open an admistrative session with the working copy. */ > - SVN_ERR(svn_wc__adm_probe_in_context(&adm_access, ctx->wc_ctx, > - target_abspath, > - (! dry_run), -1, ctx->cancel_func, > - ctx->cancel_baton, pool)); Note the DRY_RUN usage there. The old code would not consume a write lock during a dry run operation. >... Cheers, -g
Re: svn commit: r931798 - /subversion/trunk/subversion/libsvn_wc/update_editor.c
On Thu, Apr 8, 2010 at 07:34, Julian Foad wrote: > I (Julian Foad) wrote: >> gst...@apache.org wrote: >> > Author: gstein >> > Date: Thu Apr 8 07:11:58 2010 >> > New Revision: 931798 >> >> > Modified: subversion/trunk/subversion/libsvn_wc/update_editor.c >> > URL: >> > http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_wc/update_editor.c?rev=931798&r1=931797&r2=931798&view=diff >> > == >> > --- subversion/trunk/subversion/libsvn_wc/update_editor.c (original) >> > +++ subversion/trunk/subversion/libsvn_wc/update_editor.c Thu Apr 8 >> > 07:11:58 2010 >> > @@ -4257,6 +4257,7 @@ install_text_base(svn_stringbuf_t **log_ >> > static svn_error_t * >> > merge_file(svn_stringbuf_t **log_accum, >> > svn_boolean_t *install_pristine, >> > + const char **install_from, >> >> Please document the new parameters. > > This looks odd... the new parameters are being used to install a new > *working* file, not a new pristine file (although the new working file > is sometimes a copy of the pristine file). svn_boolean_t *install_from_pristine might be more appropriate. *shrug*
Re: [PATCH] Fix for issue 2753 "SVNListParentPath feature doesn't work when svn authz is used."
Kamesh Jayachandran writes:
> [issue2753] Fix issue 2753.
Let me see if I understand: The issue is that when SVNListParentPath
and AuthzSVNAccessFile are configured then GET requests for the parent
path get passed through the authz stuff. This is a bug because the
authz file doesn't control parent path.
Your patch recognises this request and avoids doing the authz check.
> Relax requests aimed at the repo Parent path from authz control.
>
> * subversion/mod_authz_svn/mod_authz_svn.c
> (req_check_access): When canonicalized 'uri' and 'root_path' are same
>allow the request.
> ]]]
>
> If there are no objections will commit this in next couple of days.
>
> Thanks
> With regards
> Kamesh Jayachandran
>
> Index: subversion/mod_authz_svn/mod_authz_svn.c
> ===
> --- subversion/mod_authz_svn/mod_authz_svn.c (revision 931820)
> +++ subversion/mod_authz_svn/mod_authz_svn.c (working copy)
> @@ -210,6 +210,8 @@
>svn_authz_t *access_conf = NULL;
>svn_error_t *svn_err;
>char errbuf[256];
> + const char *canonicalized_uri;
> + const char *canonicalized_root_path;
>const char *username_to_authorize = get_username_to_authorize(r, conf);
>
>switch (r->method_number)
> @@ -249,6 +251,15 @@
> break;
> }
>
> + canonicalized_uri = svn_uri_canonicalize(r->uri, r->pool);
> + canonicalized_root_path = svn_uri_canonicalize(conf->base_path, r->pool);
Can conf->base_path be canonicalised once in
create_authz_svn_dir_config rather than for every request?
> + if (strcmp(canonicalized_uri, canonicalized_root_path) == 0)
> +{
> + /*Do no access control when root_path(as configured in ) and
> + given uri are same.*/
> + return OK;
> +}
What happens if SVNParentPath is not being used? Is base_path is the
root of the repository? Does this disable authz on the root of that
repository? Perhaps you should be checking dav_svn__get_list_parentpath?
I think this check would make more sense in access_checker rather than
req_check_access.
The code needs a comment to say why no access control is neccessary in
this case.
> +
>dav_err = dav_svn_split_uri(r,
>r->uri,
>conf->base_path,
--
Philip
Re: svn commit: r931918 - /subversion/trunk/subversion/libsvn_client/merge.c
And with this change, there are no more adm_access_t's in libsvn_client. Yay! On Thu, Apr 8, 2010 at 7:56 AM, philip wrote: > Author: philip > Date: Thu Apr 8 12:56:16 2010 > New Revision: 931918 > > URL: http://svn.apache.org/viewvc?rev=931918&view=rev > Log: > Remove an access baton from client merge. > > * subversion/libsvn_client/merge.c > (merge_reintegrate_locked): Renamed from svn_client_merge_reintegrate, > parameter target_wcpath renamed to target_abspath, parameter pool > renamed to scratch_pool, remove access baton. > (struct merge_reintegrate_baton, merge_reintegrate_cb): New > (svn_client_merge_reintegrate): Gutted, uses svn_wc__call_with_write_lock. > > Modified: >subversion/trunk/subversion/libsvn_client/merge.c > ...
[PATCH] Fix for issue 2753 "SVNListParentPath feature doesn't work when svn authz is used."
Hi All,
Attached patch fixes issue 2753.
Quick description of 2753.
DAV svn
SVNParentPath /repositories
AuthType Basic
AuthName "My SVN"
AuthUserFile /etc/httpd/conf.d/users
allow from all
AuthzSVNAccessFile /etc/httpd/conf.d/svn_access_file
With the above configuration 'wget http://localhost/svn' gets 403 Access
forbidden.
Thrown from the following stack trace.
mod_dav_svn/repos.c:dav_svn_split_uri() <-- This function throws this
403 logging the following in the error_log
"The URI does not contain the name "
"of a repository.");
mod_authz_svn:req_check_access()
mod_authz_svn:access_checker()
The suggested work around for this issue is to define a with
a trailing slash i.e
Why this work around works?
Whatever that is defined in the or is
passed as is in the variable name 'root_path'.
dav_svn_split_uri() always removes the trailing slash of the uri.
So uri becomes '/svn' and root_path becomes '/svn' or '/svn/' based on
how it is configured in the Location block.
In the work around case
relative = ap_stripprefix("/svn", "/svn/"); //relative becomes '/svn'
and hence passes rest of the code path without error.
While 'relative' becomes empty string for ap_stripprefix("/svn", "/svn")
and hence this 403.
About the fix:
Fix is to 'relax' mod_authz_svn for 'requests' that are for the repo parent.
I tested the following cases with this patch:
With the restrictive(read-only) authz, tried to set prop on the '/' of
the repo(configured to serve via SVNPath), it failed as expected.
Ran through the testsuite, It did not break any new tests.
[[[
[issue2753] Fix issue 2753.
Relax requests aimed at the repo Parent path from authz control.
* subversion/mod_authz_svn/mod_authz_svn.c
(req_check_access): When canonicalized 'uri' and 'root_path' are same
allow the request.
]]]
If there are no objections will commit this in next couple of days.
Thanks
With regards
Kamesh Jayachandran
Index: subversion/mod_authz_svn/mod_authz_svn.c
===
--- subversion/mod_authz_svn/mod_authz_svn.c(revision 931820)
+++ subversion/mod_authz_svn/mod_authz_svn.c(working copy)
@@ -210,6 +210,8 @@
svn_authz_t *access_conf = NULL;
svn_error_t *svn_err;
char errbuf[256];
+ const char *canonicalized_uri;
+ const char *canonicalized_root_path;
const char *username_to_authorize = get_username_to_authorize(r, conf);
switch (r->method_number)
@@ -249,6 +251,15 @@
break;
}
+ canonicalized_uri = svn_uri_canonicalize(r->uri, r->pool);
+ canonicalized_root_path = svn_uri_canonicalize(conf->base_path, r->pool);
+ if (strcmp(canonicalized_uri, canonicalized_root_path) == 0)
+{
+ /*Do no access control when root_path(as configured in ) and
+ given uri are same.*/
+ return OK;
+}
+
dav_err = dav_svn_split_uri(r,
r->uri,
conf->base_path,
Re: Subversion Vision and Roadmap Proposal
A bit late perhaps, but also from me a big +1 to this vision and roadmap proposal. There are some minor points which can be discussed of course (as always), but overall I think it's a very good plan. I especially applaud the initiative itself to spend some time for this, taking a step back, looking a bit further down the road than just the next minor release or the next fire that needs to be put out, trying to get the community more focused and more active, ... This is all very important, so thanks to all who participate(d). I hope you guys can repeat this kind of gettogether once in a while, to toss ideas around, to provide continuing direction, ... Some detailed responses to the proposal and to the other replies below. On Fri, Apr 2, 2010 at 5:28 PM, C. Michael Pilato wrote: > VISION > [...] > Subversion exists to be universally recognized and adopted as an > open-source, centralized version control system characterized by its > reliability as a safe haven for valuable data; the simplicity of its > model and usage; and its ability to support the needs of a wide variety > of users and projects, from individuals to large-scale enterprise > operations. > > A shorter, business-card-sized motto (offered as a replacement to the > obsolete "A compelling replacement for CVS") might be: "Enterprise-class > centralized version control for the masses". Absolutely spot on. Subversion needs to be the best out there for centralized version control (which is what enterprises usually need/want). It has no place in the DVCS world. Like it probably also happens in other companies, in our company there are some grassroots experiments of using DVCS's. But it's not their distributedness that attracts our developers, it's simply because they are faster to work with, have better merging capabilities, better handling of renames, ... things that AFAICS do not depend on the distributed nature of the VCS. If Subversion would be able to catch up with the DVCS's in these areas (both feature-wise and especially performance-wise), I see no reason to prefer a DVCS (except of course if you need the D because you require your VCS to be uh ... distributed). > ROADMAP > [...] > 1.7: WC-NG; HTTPv2; 'svn patch'; typical slew of various bug fixes Eagerly awaiting WC-NG here. We need *fast* working copies (that know how to preserve all the information of arbitrary series of adds/moves/copies/renames/modifications/deletes correctly), and we need them now ;-). Cheering you guys on for 1.7-ness ... > 1.8: repository-dictated configuration; tree conflicts improvements; >WC-NG-enabled stuff (rename tracking, compressed pristines, >shelving/checkpointing, ...) Yes, tree conflicts improvements and rename tracking are absolutely critical. I know they have to wait for WC-NG right now, but boy do we need them... It's good to see them proposed for 1.8. Great also to see repository-dictated configuration come into the picture. In an enterprise environment the lack of this feature has always been kind of embarrassing (having to catch things in a pre-commit hook, and telling your users they have to install the correct config in their client, ...), and also a huge waste of time. > 1.9: Editor v2 (for server->client rename handling improvements) > > [...] > > 2.0: FS-NG (ideally a parallelized task), with some (to-be-identified) >FS-NG enabled features. > > That last item is likely to be contentious, so it bears explaining. We > believe that our current two filesystem offerings are stifling innovation. > On the one hand we have the BDB backend which is a breeze to develop for but > is only occasional used; on the other is the far-more-popular FSFS backend > whose fundamental principles so constrain the system as to destroy much hope > of serious design overhaul; and in the middle lies the feature parity > requirement we've been living under thus far which binds Subversion to the > union of the two backends' weaknesses. We confidently assert that to break > system-wide compatibility with a so-called 2.0 release will be Subversion's > great overall detriment, both from the perspective of efficient use of > development energy and in user adoption. So we propose that an > as-yet-fictional Subversion 2.0 be allowed to break compatibility with the > 1.x line only in ways which can be mitigated using the RA layer as a > compatibility shim. Additionally, we believe that merely releasing a 2.0 > with a new FS backend but without new user-visible features enabled by that > overhaul will be ill-received. This is the first I hear of FS-NG, but I'm quite enthousiastic. I completely understand the rationale that you give above. I especially hope that FS-NG will be *fast*. We use FSFS and I've always felt that it's not very much designed for performance (especially for big read operations like log, blame, checkout, ... which have to do way too much I/O to get the job done). Thinking back right now to a quote
Re: svn commit: r931798 - /subversion/trunk/subversion/libsvn_wc/update_editor.c
I (Julian Foad) wrote: > gst...@apache.org wrote: > > Author: gstein > > Date: Thu Apr 8 07:11:58 2010 > > New Revision: 931798 > > > Modified: subversion/trunk/subversion/libsvn_wc/update_editor.c > > URL: > > http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_wc/update_editor.c?rev=931798&r1=931797&r2=931798&view=diff > > == > > --- subversion/trunk/subversion/libsvn_wc/update_editor.c (original) > > +++ subversion/trunk/subversion/libsvn_wc/update_editor.c Thu Apr 8 > > 07:11:58 2010 > > @@ -4257,6 +4257,7 @@ install_text_base(svn_stringbuf_t **log_ > > static svn_error_t * > > merge_file(svn_stringbuf_t **log_accum, > > svn_boolean_t *install_pristine, > > + const char **install_from, > > Please document the new parameters. This looks odd... the new parameters are being used to install a new *working* file, not a new pristine file (although the new working file is sometimes a copy of the pristine file). - Julian
Re: svn commit: r931798 - /subversion/trunk/subversion/libsvn_wc/update_editor.c
gst...@apache.org wrote: > Author: gstein > Date: Thu Apr 8 07:11:58 2010 > New Revision: 931798 > Modified: subversion/trunk/subversion/libsvn_wc/update_editor.c > URL: > http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_wc/update_editor.c?rev=931798&r1=931797&r2=931798&view=diff > == > --- subversion/trunk/subversion/libsvn_wc/update_editor.c (original) > +++ subversion/trunk/subversion/libsvn_wc/update_editor.c Thu Apr 8 07:11:58 > 2010 > @@ -4257,6 +4257,7 @@ install_text_base(svn_stringbuf_t **log_ > static svn_error_t * > merge_file(svn_stringbuf_t **log_accum, > svn_boolean_t *install_pristine, > + const char **install_from, Please document the new parameters. - Julian
FW: svn commit: r931738 - in /subversion/trunk/subversion/tests/cmdline: diff_tests.py merge_tests.py
> -Original Message- > From: gst...@apache.org [mailto:gst...@apache.org] > Sent: donderdag 8 april 2010 2:28 > To: comm...@subversion.apache.org > Subject: svn commit: r931738 - in > /subversion/trunk/subversion/tests/cmdline: diff_tests.py merge_tests.py > > Author: gstein > Date: Thu Apr 8 00:28:17 2010 > New Revision: 931738 > > URL: http://svn.apache.org/viewvc?rev=931738&view=rev > Log: > XFail two more tests that throw errors because we cannot represent a > local-add within a copied subtree. > > * subversion/tests/cmdline/diff_tests.py: > (diff_in_renamed_folder): add comment about breakage > (test_list): XFail the above test > > * subversion/tests/cmdline/merge_tests.py: > (merge_catches_nonexistent_target): add comment about breakage > (test_list): XFail the above test svnsync_tests.py 16 needs the same handling. (It also fails on a local add below a copy). (This test is skipped on ra_local) Bert
Re: wc-ng base/working nodes in a copied tree
Greg Stein writes: > Okay. So I guess we continue to mark that as sched-delete. sched-delete is what we can do in 1.6, but it's not perfect. This is not a normal delete by the user it's more of an internal Subversion delete. One of the big differences is that the user cannot revert the delete, because the information about the node is not available. wc-ng could distinguish this from a normal delete. -- Philip
RE: svn commit: r931162 - in /subversion/trunk: ./ subversion/libsvn_diff/parse-diff.c subversion/tests/cmdline/patch_tests.py
> -Original Message- > From: s...@apache.org [mailto:s...@apache.org] > Sent: dinsdag 6 april 2010 16:20 > To: comm...@subversion.apache.org > Subject: svn commit: r931162 - in /subversion/trunk: ./ > subversion/libsvn_diff/parse-diff.c subversion/tests/cmdline/patch_tests.py > > Author: stsp > Date: Tue Apr 6 14:20:21 2010 > New Revision: 931162 > > URL: http://svn.apache.org/viewvc?rev=931162&view=rev > Log: > Cherry-pick r929288 and r931140 from the svn-patch-improvements branch > to trunk, fixing the problem reported in: > > Date: Wed, 3 Mar 2010 15:52:59 +0100 > From: Stefan Sperling > To: dev@subversion.apache.org > Subject: svn patch fails on this diff > Message-ID: <20100303145259.gf8...@noel.stsp.name> > http://svn.haxx.se/dev/archive-2010-03/0097.shtml > http://svn.haxx.se/dev/archive-2010-03/0098.shtml (attachment) > > Modified: subversion/trunk/subversion/tests/cmdline/patch_tests.py > URL: > http://svn.apache.org/viewvc/subversion/trunk/subversion/tests/cmdline/ > patch_tests.py?rev=931162&r1=931161&r2=931162&view=diff > == > > --- subversion/trunk/subversion/tests/cmdline/patch_tests.py (original) > +++ subversion/trunk/subversion/tests/cmdline/patch_tests.py Tue Apr 6 > 14:20:21 2010 > @@ -841,6 +841,92 @@ def patch_strip1(sbox): > 1, # dry-run > '-p1') > > +def patch_no_index_line(sbox): > + "patch with no index lines" > + > + sbox.build() > + wc_dir = sbox.wc_dir > + > + patch_file_path = > tempfile.mkstemp(dir=os.path.abspath(svntest.main.temp_dir))[1] This line reintroduces the issue I fixed in the other tests in r930990. Stefan: Answering your question: It seems the handle must be closed before leaving the function. (I don't mind where, as long as it fixes the errors) Greg: You just fixed several other functions to use open(...).read(), without closing the handle. This doesn't cause the same error, so this file is somehow closed without the explicit close required above. Do you have any idea why mkstemp() does need the explicit close? (Python bug?) Other question: Do we really need a mkstemp call here? I assumed we have a per test temporary directory where we can place any named file we want? Bert
