Re: [PATCH] Fix for issue 3826
Daniel Becroft writes: > On Thu, Mar 3, 2011 at 3:34 AM, Noorul Islam K M wrote: > >> >> Please find attached patch for issue 3826. All tests pass using 'make >> check' >> > > Hey Noorul, > > I had a quick look at this issue last night. It appears a similar issue > exists for almost every command (I checked 'info', 'status' and 'update'). > I could not replicate this for info command. See below. noorul@noorul:/tmp$ ~/projects/subversion/builds/trunk/bin/svnadmin create r1 noorul@noorul:/tmp$ ~/projects/subversion/builds/trunk/bin/svn co file://`pwd`/r1 wc1 Checked out revision 0. noorul@noorul:/tmp$ cd wc1 noorul@noorul:/tmp/wc1$ ~/projects/subversion/builds/trunk/bin/svn info /tmp/wc1 Path: . Working Copy Root Path: /tmp/wc1 URL: file:///tmp/r1 Repository Root: file:///tmp/r1 Repository UUID: f9e30c5c-08a7-45df-9e30-5f299052b040 Revision: 0 Node Kind: directory Schedule: normal Last Changed Rev: 0 Last Changed Date: 2011-03-03 09:50:13 +0530 (Thu, 03 Mar 2011) Thanks and Regards Noorul
Re: [PATCH] Fix for issue 3826
Daniel Becroft writes: > On Thu, Mar 3, 2011 at 3:34 AM, Noorul Islam K M wrote: > >> >> Please find attached patch for issue 3826. All tests pass using 'make >> check' >> > > Hey Noorul, > > I had a quick look at this issue last night. It appears a similar issue > exists for almost every command (I checked 'info', 'status' and 'update'). > I will submit followup fixes. For the time being if this patch is fine then this can committed. Thanks and Regards Noorul
Re: Subversion hackathon at Knockree Retreat (13-16 May)
On Wed, Mar 2, 2011 at 15:37, Hyrum K Wright wrote: > On Tue, Mar 1, 2011 at 4:08 PM, Nick Burch wrote: >> Hi All >> >> The Apache Conferences Committee (ConCom) are pleased to announce the 2nd >> Apache Retreat at Knockree in Ireland, from Friday 13th to Monday 16th May. >> As some of you may already known, your project is taking part in the >> retreat, and is hosting a hackathon/planning session there. >> >> For those who haven't been to an Apache Retreat before, they're a weekend >> long event when Apache committers and community members get together to hack >> on code, attend un-conference sessions, put faces to names and generally >> have a fun time. >> >> The project hackathons provide a great chance to plan new releases, solve >> bugs, try out new ideas and designs, as well as meeting people you've >> previously only emailed! The weekend will also feature a BarCamp >> un-conference, so when you're not hacking there's plenty else of interest to >> get up it. >> >> For more information on what the event is like, what the venue's like, >> what's planned and how to sign up, please see: >> https://sites.google.com/site/apacheretreatknockree/ >> >> In addition, the Travel Assistance Committee is supporting the event, and >> can fund travel for those who otherwise couldn't make it. The deadline for >> applications is Saturday 12th March, please see >> http://www.apache.org/travel/ for information on what's covered, the >> criteria and how to apply. >> >> Otherwise, we look forward to seeing your project hacking away in Ireland in >> May! > > I'll add a secondary plug for the Ireland retreat, and note that it > dovetails nicely with the elego-sponsored Berlin hackathon the > following week. Myself, Hyrum, and Stefan Sperling will be attending both events, by the way. Hope to you see you all at one or both of these!! Cheers, -g
Re: Subversion hackathon at Knockree Retreat (13-16 May)
On Tue, Mar 1, 2011 at 4:08 PM, Nick Burch wrote: > Hi All > > The Apache Conferences Committee (ConCom) are pleased to announce the 2nd > Apache Retreat at Knockree in Ireland, from Friday 13th to Monday 16th May. > As some of you may already known, your project is taking part in the > retreat, and is hosting a hackathon/planning session there. > > For those who haven't been to an Apache Retreat before, they're a weekend > long event when Apache committers and community members get together to hack > on code, attend un-conference sessions, put faces to names and generally > have a fun time. > > The project hackathons provide a great chance to plan new releases, solve > bugs, try out new ideas and designs, as well as meeting people you've > previously only emailed! The weekend will also feature a BarCamp > un-conference, so when you're not hacking there's plenty else of interest to > get up it. > > For more information on what the event is like, what the venue's like, > what's planned and how to sign up, please see: > https://sites.google.com/site/apacheretreatknockree/ > > In addition, the Travel Assistance Committee is supporting the event, and > can fund travel for those who otherwise couldn't make it. The deadline for > applications is Saturday 12th March, please see > http://www.apache.org/travel/ for information on what's covered, the > criteria and how to apply. > > Otherwise, we look forward to seeing your project hacking away in Ireland in > May! I'll add a secondary plug for the Ireland retreat, and note that it dovetails nicely with the elego-sponsored Berlin hackathon the following week. -Hyrum
Re: [PATCH] Fix for issue 3826
On Thu, Mar 3, 2011 at 3:34 AM, Noorul Islam K M wrote:
>
> Please find attached patch for issue 3826. All tests pass using 'make
> check'
>
Hey Noorul,
I had a quick look at this issue last night. It appears a similar issue
exists for almost every command (I checked 'info', 'status' and 'update').
Cheers,
Daniel B.
> Log
> [[[
>
> Fix for issue 3826. Make svn diff respect absolute paths. Also fix
> corresponding test.
>
> * subversion/svn/diff-cmd.c
> (svn_cl__diff): Do not convert absolute path into relative one.
>
> * subversion/tests/cmdline/diff_tests.py
> (diff_abs_localpath_from_wc_folder): Fix test to use correct absolute
>path. Remove XFail marker.
>
> Patch by: Noorul Islam K M
> Found by: danielsh
> ]]]
>
>
> Index: subversion/tests/cmdline/diff_tests.py
> ===
> --- subversion/tests/cmdline/diff_tests.py (revision 1076214)
> +++ subversion/tests/cmdline/diff_tests.py (working copy)
> @@ -3761,7 +3761,6 @@
> '-c2', '--git')
> os.chdir(was_cwd)
>
> -@XFail()
> @Issue(3826)
> def diff_abs_localpath_from_wc_folder(sbox):
> "diff absolute localpath from wc folder"
> @@ -3770,9 +3769,10 @@
>
> A_path = os.path.join(wc_dir, 'A')
> B_path = os.path.join(wc_dir, 'A', 'B')
> + B_abspath = os.path.abspath(B_path)
> os.chdir(os.path.abspath(A_path))
> svntest.actions.run_and_verify_svn(None, None, [], 'diff',
> - os.path.abspath(B_path))
> + B_abspath)
>
>
> #Run the tests
> Index: subversion/svn/diff-cmd.c
> ===
> --- subversion/svn/diff-cmd.c (revision 1076214)
> +++ subversion/svn/diff-cmd.c (working copy)
> @@ -324,8 +324,11 @@
> return svn_error_createf(SVN_ERR_CL_ARG_PARSING_ERROR, NULL,
> _("Path '%s' not relative to base
> URLs"),
> path);
> + if (! svn_dirent_is_absolute(path))
> +path = svn_relpath_canonicalize(path, iterpool);
> + else
> +path = svn_dirent_canonicalize(path, iterpool);
>
> - path = svn_relpath_canonicalize(path, iterpool);
> if (svn_path_is_url(old_target))
> target1 = svn_path_url_add_component2(old_target, path,
> iterpool);
> else
>
>
[PATCH] Fix for issue 3826
Please find attached patch for issue 3826. All tests pass using 'make
check'
Log
[[[
Fix for issue 3826. Make svn diff respect absolute paths. Also fix
corresponding test.
* subversion/svn/diff-cmd.c
(svn_cl__diff): Do not convert absolute path into relative one.
* subversion/tests/cmdline/diff_tests.py
(diff_abs_localpath_from_wc_folder): Fix test to use correct absolute
path. Remove XFail marker.
Patch by: Noorul Islam K M
Found by: danielsh
]]]
Index: subversion/tests/cmdline/diff_tests.py
===
--- subversion/tests/cmdline/diff_tests.py (revision 1076214)
+++ subversion/tests/cmdline/diff_tests.py (working copy)
@@ -3761,7 +3761,6 @@
'-c2', '--git')
os.chdir(was_cwd)
-@XFail()
@Issue(3826)
def diff_abs_localpath_from_wc_folder(sbox):
"diff absolute localpath from wc folder"
@@ -3770,9 +3769,10 @@
A_path = os.path.join(wc_dir, 'A')
B_path = os.path.join(wc_dir, 'A', 'B')
+ B_abspath = os.path.abspath(B_path)
os.chdir(os.path.abspath(A_path))
svntest.actions.run_and_verify_svn(None, None, [], 'diff',
- os.path.abspath(B_path))
+ B_abspath)
#Run the tests
Index: subversion/svn/diff-cmd.c
===
--- subversion/svn/diff-cmd.c (revision 1076214)
+++ subversion/svn/diff-cmd.c (working copy)
@@ -324,8 +324,11 @@
return svn_error_createf(SVN_ERR_CL_ARG_PARSING_ERROR, NULL,
_("Path '%s' not relative to base URLs"),
path);
+ if (! svn_dirent_is_absolute(path))
+path = svn_relpath_canonicalize(path, iterpool);
+ else
+path = svn_dirent_canonicalize(path, iterpool);
- path = svn_relpath_canonicalize(path, iterpool);
if (svn_path_is_url(old_target))
target1 = svn_path_url_add_component2(old_target, path, iterpool);
else
Re: [PATCH] fix for issue #3789 log -g regression in r1028108
Paul Burba wrote on 03/02/2011 10:10:40 AM: > On Wed, Mar 2, 2011 at 10:44 AM, C. Michael Pilato > wrote: > > On 03/02/2011 10:40 AM, kmra...@rockwellcollins.com wrote: > >> "C. Michael Pilato" wrote on 01/28/2011 01:44:26 PM: > >>> Subject: Re: [PATCH] fix for issue #3789 log -g regression in r1028108 > >>> > >>> On 01/26/2011 05:59 PM, Kevin Radke wrote: > >>> > This also needs a back-port to the 1.6.x branch. > >>> > > >>> > [[[ > >>> >Fix issue #3789: Correctly ignore missing locations when a > renamed file > >>> >has more than MAX_OPEN_HISTORIES. > >>> > > >>> >* subversion/libsvn_repos/log.c > >>> > (get_path_histories): Ignore more bogus repository > locations to restore > >>> >pre-1.6.15 log -g behavior. This fixes > >>> client chunk > >>> >errors introduced by r1028108. > >>> >]]] > >>> > >>> Committed this in r1064839 with tweaks to the log message. (Rather than > >>> open a new issue, I just reopened issue 3270). Will propose for > backport to > >>> 1.6.x, too. Thanks, Kevin. > >> > >> Was this ever proposed for backport? (Or am I just missing it in STATUS?) > >> > >> http://svn.apache.org/viewvc/subversion/branches/1.6.x/STATUS?view=markup > >> > >> This does fix a regression introduced with 1.6.15... > > > > Pretty confident that it did. I believe it's the "More fixes for issue > > #3270" item in CHANGES on the 1.6.x branch. > > Scratch "pretty confident" and insert "certain": > > http://svn.apache.org/viewvc?view=revision&revision=1072344 Excellent. Thanks for double checking this. (And thanks for not slapping my hand too hard for not looking in the CHANGES file... :)) Kevin R.
Re: [PATCH] fix for issue #3789 log -g regression in r1028108
On Wed, Mar 2, 2011 at 10:44 AM, C. Michael Pilato wrote: > On 03/02/2011 10:40 AM, kmra...@rockwellcollins.com wrote: >> "C. Michael Pilato" wrote on 01/28/2011 01:44:26 PM: >>> Subject: Re: [PATCH] fix for issue #3789 log -g regression in r1028108 >>> >>> On 01/26/2011 05:59 PM, Kevin Radke wrote: >>> > This also needs a back-port to the 1.6.x branch. >>> > >>> > [[[ >>> > Fix issue #3789: Correctly ignore missing locations when a renamed file >>> > has more than MAX_OPEN_HISTORIES. >>> > >>> > * subversion/libsvn_repos/log.c >>> > (get_path_histories): Ignore more bogus repository locations to >>> > restore >>> > pre-1.6.15 log -g behavior. This fixes >>> client chunk >>> > errors introduced by r1028108. >>> > ]]] >>> >>> Committed this in r1064839 with tweaks to the log message. (Rather than >>> open a new issue, I just reopened issue 3270). Will propose for backport to >>> 1.6.x, too. Thanks, Kevin. >> >> Was this ever proposed for backport? (Or am I just missing it in STATUS?) >> >> http://svn.apache.org/viewvc/subversion/branches/1.6.x/STATUS?view=markup >> >> This does fix a regression introduced with 1.6.15... > > Pretty confident that it did. I believe it's the "More fixes for issue > #3270" item in CHANGES on the 1.6.x branch. Scratch "pretty confident" and insert "certain": http://svn.apache.org/viewvc?view=revision&revision=1072344 Paul
Re: [PATCH] fix for issue #3789 log -g regression in r1028108
On 03/02/2011 10:40 AM, kmra...@rockwellcollins.com wrote: > "C. Michael Pilato" wrote on 01/28/2011 01:44:26 PM: >> Subject: Re: [PATCH] fix for issue #3789 log -g regression in r1028108 >> >> On 01/26/2011 05:59 PM, Kevin Radke wrote: >> > This also needs a back-port to the 1.6.x branch. >> > >> > [[[ >> >Fix issue #3789: Correctly ignore missing locations when a renamed file >> >has more than MAX_OPEN_HISTORIES. >> > >> >* subversion/libsvn_repos/log.c >> > (get_path_histories): Ignore more bogus repository locations to >> > restore >> >pre-1.6.15 log -g behavior. This fixes >> client chunk >> >errors introduced by r1028108. >> >]]] >> >> Committed this in r1064839 with tweaks to the log message. (Rather than >> open a new issue, I just reopened issue 3270). Will propose for backport to >> 1.6.x, too. Thanks, Kevin. > > Was this ever proposed for backport? (Or am I just missing it in STATUS?) > > http://svn.apache.org/viewvc/subversion/branches/1.6.x/STATUS?view=markup > > This does fix a regression introduced with 1.6.15... Pretty confident that it did. I believe it's the "More fixes for issue #3270" item in CHANGES on the 1.6.x branch. -- C. Michael Pilato CollabNet <> www.collab.net <> Distributed Development On Demand signature.asc Description: OpenPGP digital signature
Re: [PATCH] fix for issue #3789 log -g regression in r1028108
"C. Michael Pilato" wrote on 01/28/2011 01:44:26 PM: > Subject: Re: [PATCH] fix for issue #3789 log -g regression in r1028108 > > On 01/26/2011 05:59 PM, Kevin Radke wrote: > > This also needs a back-port to the 1.6.x branch. > > > > [[[ > >Fix issue #3789: Correctly ignore missing locations when a renamed file > >has more than MAX_OPEN_HISTORIES. > > > >* subversion/libsvn_repos/log.c > > (get_path_histories): Ignore more bogus repository locations to restore > >pre-1.6.15 log -g behavior. This fixes > client chunk > >errors introduced by r1028108. > >]]] > > Committed this in r1064839 with tweaks to the log message. (Rather than > open a new issue, I just reopened issue 3270). Will propose for backport to > 1.6.x, too. Thanks, Kevin. Was this ever proposed for backport? (Or am I just missing it in STATUS?) http://svn.apache.org/viewvc/subversion/branches/1.6.x/STATUS?view=markup This does fix a regression introduced with 1.6.15... Thanks! Kevin R.
Re: [PATCH] Add --dry-run flag to "svn update" client command
Hi All, Thanks for all the feedback. As Stefan said, yes, this patch was an immense learning experience for me and I wouldn't trade it for anything else. All said and done, I hope this is not the end of this patch. It implements exactly what the issue tracker describes and I think it would be an excellent feature enhancement. So, I would really appreciate it if this patch gets a closer look. If anybody can throw light on how this can be done any differently (not some combination of existing commands, but a working update --dry-run), I would gladly lend my ears. Thanks and regards, Arwin Arni
Re: [PATCH] Add --dry-run flag to "svn update" client command
On Wed, Mar 2, 2011 at 9:14 AM, Daniel Shahaf wrote: > Mark Phippard wrote on Wed, Mar 02, 2011 at 08:50:31 -0500: >> I also do not see why clients could not use this. Presumably it sends >> notifications just like merge --dry-run. >> > > svn up -q -r BASE && svn merge --dry-run -r BASE:HEAD ./ ./ If you all feel strongly that this feature should not be added then why haven't you closed the issue? Please add your comments to the issue and mark it as WONTFIX. -- Thanks Mark Phippard http://markphip.blogspot.com/
Re: [PATCH] Compiling subversion trunk with httpd trunk code fails
Thanks Vijay. Committed your in r1076234. With regards Kamesh Jayachandran On 03/02/2011 03:18 PM, vijay wrote: Attached the patch that uses macro based solution. APLOG_USE_MODULE is used only in case of HTTPD 2.3. Thanks & Regards, Vijayaguru On Wednesday 02 March 2011 12:20 AM, Stefan Sperling wrote: On Tue, Mar 01, 2011 at 11:08:22PM +0530, Kamesh Jayachandran wrote: On the whole I preferred the macro solution. Me to prefer the orignal macro based solution. OK. Let's go for that, then.
Re: [PATCH] Add --dry-run flag to "svn update" client command
On 03/02/2011 07:47 PM, Daniel Shahaf wrote: Bert Huijben wrote on Wed, Mar 02, 2011 at 11:14:24 +0100: -Original Message- From: Arwin Arni [mailto:ar...@collab.net] Please review this and share your thoughts. I don't think this is the way we should implement this. Which is precisely why one should contact the mailing list BEFORE writing a patch. Especially a large/long patch such as this one. Daniel, Let me share *my* concern here in proposing a idea to any *new* community. I would be happy to propose an idea where I lack direction and have a ambiguity in implementation. I would be happy to post a patch if idea is simpler enough which is the case here. Yes one can declare in advance what they wish to work on, But this declaration has a negative side effect of stigma if the idea is not complete in implementation especially this stigma is too much for a newcomer. As a newcomer I would post a working patch than start a discussion(of course only if the idea is straightforward) which is often open-ended and confuses/discourages the new-comer if he is *not* that serious about the feature he proposes. With regards Kamesh Jayachandran
Re: [PATCH] Add --dry-run flag to "svn update" client command
On Wed, Mar 02, 2011 at 04:17:33PM +0200, Daniel Shahaf wrote: > Bert Huijben wrote on Wed, Mar 02, 2011 at 11:14:24 +0100: > > > -Original Message- > > > From: Arwin Arni [mailto:ar...@collab.net] > > > Please review this and share your thoughts. > > > > I don't think this is the way we should implement this. > > Which is precisely why one should contact the mailing list BEFORE > writing a patch. Especially a large/long patch such as this one. Well, Arwin said that he did this partly to learn about the update editor. So there's still value in having written that patch, even if it doesn't end up being applied. I've written a lot of diffs that never went anywhere. I never regretted this because I usually learned something new along the way.
Re: [PATCH] Add --dry-run flag to "svn update" client command
Bert Huijben wrote on Wed, Mar 02, 2011 at 11:14:24 +0100: > > -Original Message- > > From: Arwin Arni [mailto:ar...@collab.net] > > Please review this and share your thoughts. > > I don't think this is the way we should implement this. Which is precisely why one should contact the mailing list BEFORE writing a patch. Especially a large/long patch such as this one.
Re: [PATCH] Add --dry-run flag to "svn update" client command
On Mar 2, 2011, at 7:50 AM, Mark Phippard wrote: > On Wed, Mar 2, 2011 at 8:42 AM, Hyrum K Wright wrote: >> On Wed, Mar 2, 2011 at 4:14 AM, Bert Huijben wrote: >> >> Agreed. I'm not a fan of duplicating this functionality (and >> maintaining them in parallel when they inevitably drift) as part of >> 'svn up'. Let's improve what we already have, rather than inventing >> 'svn st -U' > > I think Arwin has some good points. Unless we let update do its thing > and discard the updates we cannot know if there are going to be > conflicts. I do not think svn st -U would ever grow a feature like > that would it? > > I also do not see why clients could not use this. Presumably it sends > notifications just like merge --dry-run. Indeed, I have these tips for users because (1) "update" does not have a --dry-run that will show conflicts, and (2) "status -U" also does not show that information. Knowing ahead-of-time if an update will produce conflicts is useful information. Run the merge command like this (recursive by default) to see what files would get modified and how, including which would have conflicts: svn merge -r BASE:HEAD --dry-run . To see the changes that update would try to merge, run this command: svn diff -r BASE:HEAD [list of files and directories] -Travis
Re: [PATCH] Add --dry-run flag to "svn update" client command
Mark Phippard wrote on Wed, Mar 02, 2011 at 08:50:31 -0500: > I also do not see why clients could not use this. Presumably it sends > notifications just like merge --dry-run. > svn up -q -r BASE && svn merge --dry-run -r BASE:HEAD ./ ./
Re: svn commit: r1072519 - in /subversion/trunk: ./ subversion/include/svn_io.h subversion/libsvn_subr/stream.c subversion/libsvn_subr/subst.c subversion/tests/libsvn_subr/stream-test.c
On Sun, Feb 20, 2011 at 02:05, wrote: > Author: stefan2 > Date: Sun Feb 20 07:05:56 2011 > New Revision: 1072519 > > URL: http://svn.apache.org/viewvc?rev=1072519&view=rev > Log: > Merge all changes (r1068695 - r1072516) from the > integrate-stream-api-extensions. > > These patches add svn_stream_skip(), svn_stream_buffered() > and svn_stream_supports_mark(). I don't see any users of these three functions. What are they intended for? Some future patch? And if that patch is NOT going to land for 1.7, could we back these functions out until they are needed? I'm very hesitant to continue expanding our stream concept. It used to be a very simple read/write thing, but has grown into a much more complex beast. I fear that we're making things more complex than they need to be, rather than finding simpler solutions. Thanks, -g
Re: [PATCH] Add --dry-run flag to "svn update" client command
On Wed, Mar 2, 2011 at 8:42 AM, Hyrum K Wright wrote: > On Wed, Mar 2, 2011 at 4:14 AM, Bert Huijben wrote: >> >> >>> -Original Message- >>> From: Arwin Arni [mailto:ar...@collab.net] >>> Sent: woensdag 2 maart 2011 10:49 >>> To: dev@subversion.apache.org >>> Subject: [PATCH] Add --dry-run flag to "svn update" client command >>> >>> Hi All, >>> >>> In my effort to understand the delta editor API, I took it upon myself >>> to try and implement the --dry-run flag for "svn update". >>> With Kamesh's guidance, I think I've managed to pull it off. >>> >>> Here is the relevant Issue. >>> http://subversion.tigris.org/issues/show_bug.cgi?id=2491 >>> >>> I have attached a log message and a patch that implements --dry-run for >>> update. >>> >>> Currently, externals are handled inside >>> subversion/libsvn_client/externals.c by running checkout/switch. For a >>> dry-run update to mimic a real update, the notifications have to be the >>> same. Since some of these notifications are generated by the above >>> mentioned checkout/switch runs, I have to implement dry-run for them >>> also. I'll take this up as a follow-up exercise. Now, the dry-run will >>> simply ignore any externals in the working copy. >>> >>> Please review this and share your thoughts. >> >> I don't think this is the way we should implement this. >> >> This patch adds an if before every operation in the update editor that >> changes the working copy. This makes the update editor harder to maintain, >> while you really only need a simple editor implementation that notifies its >> output to get a dry run output. >> >> That would allow the dry run code to be maintained independently without >> obfuscating the existing update editor. >> >> >> Besides: I don't know why the update editor really needs --dry run support. >> We always told our users to use svn status -U, which shows the same >> information in a generally more useful output. >> >> A dry run update is a nice feature for 'svn' with console notification, but >> implemented this way it doesn't help any other Subversion client, while >> status -U does. Should we improve status -U instead? > > Agreed. I'm not a fan of duplicating this functionality (and > maintaining them in parallel when they inevitably drift) as part of > 'svn up'. Let's improve what we already have, rather than inventing > 'svn st -U' I think Arwin has some good points. Unless we let update do its thing and discard the updates we cannot know if there are going to be conflicts. I do not think svn st -U would ever grow a feature like that would it? I also do not see why clients could not use this. Presumably it sends notifications just like merge --dry-run. -- Thanks Mark Phippard http://markphip.blogspot.com/
Re: [PATCH] Add --dry-run flag to "svn update" client command
On Wed, Mar 2, 2011 at 4:14 AM, Bert Huijben wrote: > > >> -Original Message- >> From: Arwin Arni [mailto:ar...@collab.net] >> Sent: woensdag 2 maart 2011 10:49 >> To: dev@subversion.apache.org >> Subject: [PATCH] Add --dry-run flag to "svn update" client command >> >> Hi All, >> >> In my effort to understand the delta editor API, I took it upon myself >> to try and implement the --dry-run flag for "svn update". >> With Kamesh's guidance, I think I've managed to pull it off. >> >> Here is the relevant Issue. >> http://subversion.tigris.org/issues/show_bug.cgi?id=2491 >> >> I have attached a log message and a patch that implements --dry-run for >> update. >> >> Currently, externals are handled inside >> subversion/libsvn_client/externals.c by running checkout/switch. For a >> dry-run update to mimic a real update, the notifications have to be the >> same. Since some of these notifications are generated by the above >> mentioned checkout/switch runs, I have to implement dry-run for them >> also. I'll take this up as a follow-up exercise. Now, the dry-run will >> simply ignore any externals in the working copy. >> >> Please review this and share your thoughts. > > I don't think this is the way we should implement this. > > This patch adds an if before every operation in the update editor that > changes the working copy. This makes the update editor harder to maintain, > while you really only need a simple editor implementation that notifies its > output to get a dry run output. > > That would allow the dry run code to be maintained independently without > obfuscating the existing update editor. > > > Besides: I don't know why the update editor really needs --dry run support. > We always told our users to use svn status -U, which shows the same > information in a generally more useful output. > > A dry run update is a nice feature for 'svn' with console notification, but > implemented this way it doesn't help any other Subversion client, while > status -U does. Should we improve status -U instead? Agreed. I'm not a fan of duplicating this functionality (and maintaining them in parallel when they inevitably drift) as part of 'svn up'. Let's improve what we already have, rather than inventing 'svn st -U' -Hyrum
Re: svn commit: r1076098 - /subversion/trunk/subversion/libsvn_wc/wc_db_pdh.c
Thanks.
On Wed, Mar 2, 2011 at 4:09 AM, Greg Stein wrote:
> fixed in r1076161
>
> On Wed, Mar 2, 2011 at 05:04, Greg Stein wrote:
>> Line 564 of wc_db_pdh.c is the culprit.
>>
>> Figuring out a fix...
>>
>>
>> On Wed, Mar 2, 2011 at 05:03, Greg Stein wrote:
>>> Somehow, this broke the build.
>>>
>>> Investigating...
>>>
>>>
>>> On Tue, Mar 1, 2011 at 22:07, wrote:
Author: hwright
Date: Wed Mar 2 03:07:04 2011
New Revision: 1076098
URL: http://svn.apache.org/viewvc?rev=1076098&view=rev
Log:
* subversion/libsvn_wc/wc_db_pdh.c
(pdh_parse_local_abspath): Followup to r1076093 by further allocating
bits of
the PDH in the result pool, rather than the db->state_pool.
Modified:
subversion/trunk/subversion/libsvn_wc/wc_db_pdh.c
Modified: subversion/trunk/subversion/libsvn_wc/wc_db_pdh.c
URL:
http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_wc/wc_db_pdh.c?rev=1076098&r1=1076097&r2=1076098&view=diff
==
--- subversion/trunk/subversion/libsvn_wc/wc_db_pdh.c (original)
+++ subversion/trunk/subversion/libsvn_wc/wc_db_pdh.c Wed Mar 2 03:07:04
2011
@@ -350,7 +350,7 @@ pdh_parse_local_abspath(db_pdh_t **pdh,
if (wcroot != NULL)
{
*pdh = apr_pcalloc(result_pool, sizeof(**pdh));
- (*pdh)->local_abspath = apr_pstrdup(db->state_pool, local_abspath);
+ (*pdh)->local_abspath = apr_pstrdup(result_pool, local_abspath);
(*pdh)->wcroot = wcroot;
}
else
@@ -397,7 +397,7 @@ pdh_parse_local_abspath(db_pdh_t **pdh,
if (wcroot != NULL)
{
*pdh = apr_pcalloc(result_pool, sizeof(**pdh));
- (*pdh)->local_abspath = apr_pstrdup(db->state_pool,
local_abspath);
+ (*pdh)->local_abspath = apr_pstrdup(result_pool, local_abspath);
(*pdh)->wcroot = wcroot;
}
@@ -437,7 +437,7 @@ pdh_parse_local_abspath(db_pdh_t **pdh,
if (*pdh == NULL)
{
*pdh = apr_pcalloc(result_pool, sizeof(**pdh));
- (*pdh)->local_abspath = apr_pstrdup(db->state_pool, local_abspath);
+ (*pdh)->local_abspath = apr_pstrdup(result_pool, local_abspath);
}
else
{
>>>
>>
>
Re: strange caracteres
The encoding is more likely to be a file-wide attribute, therefore it makes more sense to carry that information in a file property. In the past, I've been in favor of adding an svn:encoding or svn:charset property; others have suggested simply using the "; charset=latin1" bit that can be tagged onto the existing svn:mime-type property for the same purpose. On 03/01/2011 11:57 PM, Kevin Grover wrote: > I just read that report and could not see a way to add comments, so I'm > replying here. I know I should really send this to the subversion, list, > I'll cc them. > > Couldn't we just 'extent' the keyword syntax to include an encoding > > $Id[latin1]$ > > or $Id:latin1$ --- probably ambiguous > > or some other format (a SPECIAL Keyword to set encoding) > > $KeywordEncoding[latin1]$$Id$ > > $Date$ > > etc... > > Where the $KeywordEncoding[]$ is consumed and no bytes are > output. > > Having the special keyword $KeywordEncoding[]$ would be the > most transparent to users and probably the simplest and most useful. > > > On Sat, Feb 26, 2011 at 09:10, Stefan Küng wrote: > >> On 26.02.2011 16:58, rubis wrote: >>> Good morning Exuser me from my English but I am francais >>> >>> I have a probleme with TortoiseSVN 1.6.12, Build 20536 and windows XP SP3 >>> And autoprops >>> >>> Under linux debian I have no probleme >>> >>> local on debian >>> >>> groenland:/depot# locale >> [snip] >> >>> When I edite a file I have >>> >>> >>> # Renseignements de révision de SVN : >>> # SVN: $Revision: 11 $ >>> # SVN: $Author: stephane $ >>> # SVN: $Date: 2011-02-26 16:30:46 +0100 (sam. 26 févr. 2011) $ >>> >>> >>> I have therefore for February of the strange caracteres févr >> >> That's a known issue in the svn library: >> http://subversion.tigris.org/issues/show_bug.cgi?id=2332 >> >> For now, all keywords are expanded as utf8. But your file seems to be in >> local encoding so you see the utf8 encoded chars as they are, i.e., not >> properly encoded. >> >> >> Stefan >> >> -- >>___ >> oo // \\ "De Chelonian Mobile" >> (_,\/ \_/ \ TortoiseSVN >>\ \_/_\_/>The coolest Interface to (Sub)Version Control >>/_/ \_\ http://tortoisesvn.net >> >> -- >> >> http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2707819 >> >> To unsubscribe from this discussion, e-mail: [ >> users-unsubscr...@tortoisesvn.tigris.org]. >> > -- C. Michael Pilato CollabNet <> www.collab.net <> Distributed Development On Demand signature.asc Description: OpenPGP digital signature
Re: [PATCH] issue #3719 fix slow large checkouts on Windows
On Wed, Mar 02, 2011 at 08:31:01AM +, Neil Bird wrote: > Around about 01/03/11 17:13, Stefan Sperling typed ... > >Great! Here's a new version that includes a fix for the lock_tests > >failures. I'll propose this for backport now. Thanks for providing > >the initial patch submission for this and for helping with testing! > > Yep, that's the kiddie! Thanks for the effort; I'm only sorry I > couldn't be of any actual help bar testing in the end :) You've been great help. The fact alone that you started writing a patch made this issue more likely to get fixed because patch submissions generally receive more attention than "me too!" problem reports. This is not because such problem reports aren't being taken seriously. It's because there's an additional incentive for existing developers to keep an extra eye on patch submissions. Because that's how we can grow the team :) So I hope you'll come back some day and fix another problem, however small it might be, and that you've enjoyed this exercise even if you don't have any reason to come back.
Re: What is the most simple way to use svn_stream_t?
Use svn_stream_from_stringbuf(). That will put the contents of the file into the stringbuf, which you can access after the cat2() call is done. NOTE: be very careful of reading file contents into memory. You really don't want to try and read a 16 gigabyte file this way. Cheers, -g On Wed, Mar 2, 2011 at 03:29, Grigory Petrov wrote: > Hello. > > I need to programmatically get content of a specified revision of > versioned file. I think svn_client_cat2() will do a good job, but the > first parameter, "svn_stream_t* out" puzzles me a bit. I have read > about "streams" in corresponding header file (not a very long reading) > and it seems to be that using stream as output buffer for > svn_client_cat2() is terribly complicated: i need to create stream, > supply it to baton and read/write functions, write code for that > functions that will queue and dequeue bindary data to and from buffer > associated with baton... This seems to be a lot of code. Is it any way > to create a simple svn_stream_t* that will act as a memory buffer so i > can give it to svn_client_cat2() and on success just get all data > received as a single memory buffer? > > Any comments and insights are welcome! > > Best, > Grigory. >
Re: [PATCH] Add --dry-run flag to "svn update" client command
Hi Bert, I don't think this is the way we should implement this. This patch adds an if before every operation in the update editor that changes the working copy. This makes the update editor harder to maintain, while you really only need a simple editor implementation that notifies its output to get a dry run output. That would allow the dry run code to be maintained independently without obfuscating the existing update editor. I actually just followed the model used in merge dry run. If I were to implement my own editor, I felt that I would be duplicating a lot of code which already exists in the update editor. (w.r.t conflict detection, property handling and lots more) Besides: I don't know why the update editor really needs --dry run support. We always told our users to use svn status -U, which shows the same information in a generally more useful output. IIRC, status -U doesn't tell the user if there are going to be any text/prop conflicts upon performing the update (which I think is the primary use-case of this dry-run flag), it merely tells you if a file has been modified and if there is a newer version on the server. Moreover, status doesn't accept an -r option. A dry run update is a nice feature for 'svn' with console notification, but implemented this way it doesn't help any other Subversion client, while status -U does. Should we improve status -U instead? I have actually percolated the dry_run parameter all the way to the API. svn_client_update4 accepts this boolean and the notify_func provided by the client does the notification. I don't understand why this wouldn't help any other Subversion client. Thanks and Regards, Arwin Arni
RE: [PATCH] Add --dry-run flag to "svn update" client command
> -Original Message- > From: Arwin Arni [mailto:ar...@collab.net] > Sent: woensdag 2 maart 2011 10:49 > To: dev@subversion.apache.org > Subject: [PATCH] Add --dry-run flag to "svn update" client command > > Hi All, > > In my effort to understand the delta editor API, I took it upon myself > to try and implement the --dry-run flag for "svn update". > With Kamesh's guidance, I think I've managed to pull it off. > > Here is the relevant Issue. > http://subversion.tigris.org/issues/show_bug.cgi?id=2491 > > I have attached a log message and a patch that implements --dry-run for > update. > > Currently, externals are handled inside > subversion/libsvn_client/externals.c by running checkout/switch. For a > dry-run update to mimic a real update, the notifications have to be the > same. Since some of these notifications are generated by the above > mentioned checkout/switch runs, I have to implement dry-run for them > also. I'll take this up as a follow-up exercise. Now, the dry-run will > simply ignore any externals in the working copy. > > Please review this and share your thoughts. I don't think this is the way we should implement this. This patch adds an if before every operation in the update editor that changes the working copy. This makes the update editor harder to maintain, while you really only need a simple editor implementation that notifies its output to get a dry run output. That would allow the dry run code to be maintained independently without obfuscating the existing update editor. Besides: I don't know why the update editor really needs --dry run support. We always told our users to use svn status -U, which shows the same information in a generally more useful output. A dry run update is a nice feature for 'svn' with console notification, but implemented this way it doesn't help any other Subversion client, while status -U does. Should we improve status -U instead? Bert
Re: svn commit: r1076098 - /subversion/trunk/subversion/libsvn_wc/wc_db_pdh.c
fixed in r1076161
On Wed, Mar 2, 2011 at 05:04, Greg Stein wrote:
> Line 564 of wc_db_pdh.c is the culprit.
>
> Figuring out a fix...
>
>
> On Wed, Mar 2, 2011 at 05:03, Greg Stein wrote:
>> Somehow, this broke the build.
>>
>> Investigating...
>>
>>
>> On Tue, Mar 1, 2011 at 22:07, wrote:
>>> Author: hwright
>>> Date: Wed Mar 2 03:07:04 2011
>>> New Revision: 1076098
>>>
>>> URL: http://svn.apache.org/viewvc?rev=1076098&view=rev
>>> Log:
>>> * subversion/libsvn_wc/wc_db_pdh.c
>>> (pdh_parse_local_abspath): Followup to r1076093 by further allocating bits
>>> of
>>> the PDH in the result pool, rather than the db->state_pool.
>>>
>>> Modified:
>>> subversion/trunk/subversion/libsvn_wc/wc_db_pdh.c
>>>
>>> Modified: subversion/trunk/subversion/libsvn_wc/wc_db_pdh.c
>>> URL:
>>> http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_wc/wc_db_pdh.c?rev=1076098&r1=1076097&r2=1076098&view=diff
>>> ==
>>> --- subversion/trunk/subversion/libsvn_wc/wc_db_pdh.c (original)
>>> +++ subversion/trunk/subversion/libsvn_wc/wc_db_pdh.c Wed Mar 2 03:07:04
>>> 2011
>>> @@ -350,7 +350,7 @@ pdh_parse_local_abspath(db_pdh_t **pdh,
>>> if (wcroot != NULL)
>>> {
>>> *pdh = apr_pcalloc(result_pool, sizeof(**pdh));
>>> - (*pdh)->local_abspath = apr_pstrdup(db->state_pool, local_abspath);
>>> + (*pdh)->local_abspath = apr_pstrdup(result_pool, local_abspath);
>>> (*pdh)->wcroot = wcroot;
>>> }
>>> else
>>> @@ -397,7 +397,7 @@ pdh_parse_local_abspath(db_pdh_t **pdh,
>>> if (wcroot != NULL)
>>> {
>>> *pdh = apr_pcalloc(result_pool, sizeof(**pdh));
>>> - (*pdh)->local_abspath = apr_pstrdup(db->state_pool,
>>> local_abspath);
>>> + (*pdh)->local_abspath = apr_pstrdup(result_pool, local_abspath);
>>> (*pdh)->wcroot = wcroot;
>>> }
>>>
>>> @@ -437,7 +437,7 @@ pdh_parse_local_abspath(db_pdh_t **pdh,
>>> if (*pdh == NULL)
>>> {
>>> *pdh = apr_pcalloc(result_pool, sizeof(**pdh));
>>> - (*pdh)->local_abspath = apr_pstrdup(db->state_pool, local_abspath);
>>> + (*pdh)->local_abspath = apr_pstrdup(result_pool, local_abspath);
>>> }
>>> else
>>> {
>>>
>>>
>>>
>>
>
Re: svn commit: r1076098 - /subversion/trunk/subversion/libsvn_wc/wc_db_pdh.c
Line 564 of wc_db_pdh.c is the culprit.
Figuring out a fix...
On Wed, Mar 2, 2011 at 05:03, Greg Stein wrote:
> Somehow, this broke the build.
>
> Investigating...
>
>
> On Tue, Mar 1, 2011 at 22:07, wrote:
>> Author: hwright
>> Date: Wed Mar 2 03:07:04 2011
>> New Revision: 1076098
>>
>> URL: http://svn.apache.org/viewvc?rev=1076098&view=rev
>> Log:
>> * subversion/libsvn_wc/wc_db_pdh.c
>> (pdh_parse_local_abspath): Followup to r1076093 by further allocating bits
>> of
>> the PDH in the result pool, rather than the db->state_pool.
>>
>> Modified:
>> subversion/trunk/subversion/libsvn_wc/wc_db_pdh.c
>>
>> Modified: subversion/trunk/subversion/libsvn_wc/wc_db_pdh.c
>> URL:
>> http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_wc/wc_db_pdh.c?rev=1076098&r1=1076097&r2=1076098&view=diff
>> ==
>> --- subversion/trunk/subversion/libsvn_wc/wc_db_pdh.c (original)
>> +++ subversion/trunk/subversion/libsvn_wc/wc_db_pdh.c Wed Mar 2 03:07:04
>> 2011
>> @@ -350,7 +350,7 @@ pdh_parse_local_abspath(db_pdh_t **pdh,
>> if (wcroot != NULL)
>> {
>> *pdh = apr_pcalloc(result_pool, sizeof(**pdh));
>> - (*pdh)->local_abspath = apr_pstrdup(db->state_pool, local_abspath);
>> + (*pdh)->local_abspath = apr_pstrdup(result_pool, local_abspath);
>> (*pdh)->wcroot = wcroot;
>> }
>> else
>> @@ -397,7 +397,7 @@ pdh_parse_local_abspath(db_pdh_t **pdh,
>> if (wcroot != NULL)
>> {
>> *pdh = apr_pcalloc(result_pool, sizeof(**pdh));
>> - (*pdh)->local_abspath = apr_pstrdup(db->state_pool,
>> local_abspath);
>> + (*pdh)->local_abspath = apr_pstrdup(result_pool, local_abspath);
>> (*pdh)->wcroot = wcroot;
>> }
>>
>> @@ -437,7 +437,7 @@ pdh_parse_local_abspath(db_pdh_t **pdh,
>> if (*pdh == NULL)
>> {
>> *pdh = apr_pcalloc(result_pool, sizeof(**pdh));
>> - (*pdh)->local_abspath = apr_pstrdup(db->state_pool, local_abspath);
>> + (*pdh)->local_abspath = apr_pstrdup(result_pool, local_abspath);
>> }
>> else
>> {
>>
>>
>>
>
RE: svn commit: r1075984 - /subversion/branches/1.6.x/STATUS
> -Original Message- > From: Daniel Shahaf [mailto:d...@daniel.shahaf.name] > Sent: woensdag 2 maart 2011 4:13 > To: Bert Huijben > Cc: dev@subversion.apache.org > Subject: Re: svn commit: r1075984 - /subversion/branches/1.6.x/STATUS > > Bert Huijben wrote on Tue, Mar 01, 2011 at 23:06:33 +0100: > > (Our test suite assumes a shared library apr). > > How does the test suite assume that? (Is it the build.conf settings for > the C tests?) win-tests.py wants to copy the apr dll's to the right location and if it doesn't find these DLL's it fails before even starting the first test. Bert
Re: svn commit: r1076098 - /subversion/trunk/subversion/libsvn_wc/wc_db_pdh.c
Somehow, this broke the build.
Investigating...
On Tue, Mar 1, 2011 at 22:07, wrote:
> Author: hwright
> Date: Wed Mar 2 03:07:04 2011
> New Revision: 1076098
>
> URL: http://svn.apache.org/viewvc?rev=1076098&view=rev
> Log:
> * subversion/libsvn_wc/wc_db_pdh.c
> (pdh_parse_local_abspath): Followup to r1076093 by further allocating bits of
> the PDH in the result pool, rather than the db->state_pool.
>
> Modified:
> subversion/trunk/subversion/libsvn_wc/wc_db_pdh.c
>
> Modified: subversion/trunk/subversion/libsvn_wc/wc_db_pdh.c
> URL:
> http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_wc/wc_db_pdh.c?rev=1076098&r1=1076097&r2=1076098&view=diff
> ==
> --- subversion/trunk/subversion/libsvn_wc/wc_db_pdh.c (original)
> +++ subversion/trunk/subversion/libsvn_wc/wc_db_pdh.c Wed Mar 2 03:07:04 2011
> @@ -350,7 +350,7 @@ pdh_parse_local_abspath(db_pdh_t **pdh,
> if (wcroot != NULL)
> {
> *pdh = apr_pcalloc(result_pool, sizeof(**pdh));
> - (*pdh)->local_abspath = apr_pstrdup(db->state_pool, local_abspath);
> + (*pdh)->local_abspath = apr_pstrdup(result_pool, local_abspath);
> (*pdh)->wcroot = wcroot;
> }
> else
> @@ -397,7 +397,7 @@ pdh_parse_local_abspath(db_pdh_t **pdh,
> if (wcroot != NULL)
> {
> *pdh = apr_pcalloc(result_pool, sizeof(**pdh));
> - (*pdh)->local_abspath = apr_pstrdup(db->state_pool, local_abspath);
> + (*pdh)->local_abspath = apr_pstrdup(result_pool, local_abspath);
> (*pdh)->wcroot = wcroot;
> }
>
> @@ -437,7 +437,7 @@ pdh_parse_local_abspath(db_pdh_t **pdh,
> if (*pdh == NULL)
> {
> *pdh = apr_pcalloc(result_pool, sizeof(**pdh));
> - (*pdh)->local_abspath = apr_pstrdup(db->state_pool, local_abspath);
> + (*pdh)->local_abspath = apr_pstrdup(result_pool, local_abspath);
> }
> else
> {
>
>
>
Re: [PATCH] Compiling subversion trunk with httpd trunk code fails
Attached the patch that uses macro based solution. APLOG_USE_MODULE is
used only in case of HTTPD 2.3.
Thanks & Regards,
Vijayaguru
On Wednesday 02 March 2011 12:20 AM, Stefan Sperling wrote:
On Tue, Mar 01, 2011 at 11:08:22PM +0530, Kamesh Jayachandran wrote:
On the whole I preferred the macro solution.
Me to prefer the orignal macro based solution.
OK. Let's go for that, then.
[[[
Update log_access_verdict to make it work with HTTPD trunk as well as older
server versions with reference to [1]. The function is being called
with APLOG_MARK in few places. The macro APLOG_MARK expands to 2 arguments
till HTTPD-2.2.x but 3 arguments in HTTPD-2.3-dev, which causes failure
while compiling with HTTPD-2.3-dev. So we need to handle both the cases.
case 1-HTTPD 2.3:
1.APLOG_USE_MODULE is used to indirectly set APLOG_MODULE_INDEX and APLOG_MARK.
2.The macros LOG_ARGS_SIGNATURE and LOG_ARGS_CASCADE are expanded as formal and
actual arguments to log_access_verdict with respect to APLOG_MARK which has
one additonal parameter module_index through which we can take the advantage of
per-module loglevel configuration introduced in HTTPD 2.3.
case 2-pre-HTTPD 2.3:
The macros LOG_ARGS_SIGNATURE and LOG_ARGS_CASCADE exapnd to FILE and LINE to
make the code compatible with older server versions.
* subversion/mod_authz_svn/mod_authz_svn.c
(log_access_verdict): Pass the macro LOG_ARGS_SIGNATURE as formal parameter
and use LOG_ARGS_CASCADE as actual parameter.
[1]
http://httpd.apache.org/docs/trunk/developer/new_api_2_4.html#upgrading_logging
Patch by: Vijayaguru G
Suggested by: kameshj
]]]
Index: subversion/mod_authz_svn/mod_authz_svn.c
===
--- subversion/mod_authz_svn/mod_authz_svn.c(revision 1075316)
+++ subversion/mod_authz_svn/mod_authz_svn.c(working copy)
@@ -30,8 +30,10 @@
#include
#include
#include
+#include
#include
#include
+#include
#include
#include
#include
@@ -48,6 +50,10 @@
extern module AP_MODULE_DECLARE_DATA authz_svn_module;
+#ifdef APLOG_USE_MODULE
+APLOG_USE_MODULE(authz_svn);
+#endif
+
typedef struct authz_svn_config_rec {
int authoritative;
int anonymous;
@@ -519,12 +525,26 @@
return OK;
}
+/* The macros LOG_ARGS_SIGNATURE and LOG_ARGS_CASCADE are expanded as formal
+ * and actual parameters to log_access_verdict with respect to HTTPD version.
+ */
+#if AP_MODULE_MAGIC_AT_LEAST(20100606,0)
+#define LOG_ARGS_SIGNATURE const char *file, int line, int module_index
+#define LOG_ARGS_CASCADE file, line, module_index
+#else
+#define LOG_ARGS_SIGNATURE const char *file, int line
+#define LOG_ARGS_CASCADE file, line
+#endif
+
/* Log a message indicating the access control decision made about a
- * request. FILE and LINE should be supplied via the APLOG_MARK macro.
- * ALLOWED is boolean. REPOS_PATH and DEST_REPOS_PATH are information
+ * request. The macro LOG_ARGS_SIGNATURE expands to FILE, LINE and
+ * MODULE_INDEX in HTTPD 2.3 as APLOG_MARK macro has been changed for
+ * per-module loglevel configuration. It expands to FILE and LINE
+ * in older server versions. ALLOWED is boolean.
+ * REPOS_PATH and DEST_REPOS_PATH are information
* about the request. DEST_REPOS_PATH may be NULL. */
static void
-log_access_verdict(const char *file, int line,
+log_access_verdict(LOG_ARGS_SIGNATURE,
const request_rec *r, int allowed,
const char *repos_path, const char *dest_repos_path)
{
@@ -534,22 +554,22 @@
if (r->user)
{
if (dest_repos_path)
-ap_log_rerror(file, line, level, 0, r,
+ap_log_rerror(LOG_ARGS_CASCADE, level, 0, r,
"Access %s: '%s' %s %s %s", verdict, r->user,
r->method, repos_path, dest_repos_path);
else
-ap_log_rerror(file, line, level, 0, r,
+ap_log_rerror(LOG_ARGS_CASCADE, level, 0, r,
"Access %s: '%s' %s %s", verdict, r->user,
r->method, repos_path);
}
else
{
if (dest_repos_path)
-ap_log_rerror(file, line, level, 0, r,
+ap_log_rerror(LOG_ARGS_CASCADE, level, 0, r,
"Access %s: - %s %s %s", verdict,
r->method, repos_path, dest_repos_path);
else
-ap_log_rerror(file, line, level, 0, r,
+ap_log_rerror(LOG_ARGS_CASCADE, level, 0, r,
"Access %s: - %s %s", verdict,
r->method, repos_path);
}
Re: [PATCH] issue #3719 fix slow large checkouts on Windows
Around about 01/03/11 17:13, Stefan Sperling typed ... Great! Here's a new version that includes a fix for the lock_tests failures. I'll propose this for backport now. Thanks for providing the initial patch submission for this and for helping with testing! Yep, that's the kiddie! Thanks for the effort; I'm only sorry I couldn't be of any actual help bar testing in the end :) -- [neil@fnx ~]# rm -f .signature [neil@fnx ~]# ls -l .signature ls: .signature: No such file or directory [neil@fnx ~]# exit
What is the most simple way to use svn_stream_t?
Hello. I need to programmatically get content of a specified revision of versioned file. I think svn_client_cat2() will do a good job, but the first parameter, "svn_stream_t* out" puzzles me a bit. I have read about "streams" in corresponding header file (not a very long reading) and it seems to be that using stream as output buffer for svn_client_cat2() is terribly complicated: i need to create stream, supply it to baton and read/write functions, write code for that functions that will queue and dequeue bindary data to and from buffer associated with baton... This seems to be a lot of code. Is it any way to create a simple svn_stream_t* that will act as a memory buffer so i can give it to svn_client_cat2() and on success just get all data received as a single memory buffer? Any comments and insights are welcome! Best, Grigory.
