headers
Subversion Translation Status | 1 Mar 2011 05:22
Picon
Favicon

[l10n] Translation status report for trunk r1075650

Translation status report for trunk <at> r1075650

  lang   trans untrans   fuzzy     obs
--------------------------------------
    de    2048     132     252     216
    es    1985     195     283     354
    fr    2170      10      22      22
    it    1838     342     477     174
    ja    1976     204     352     602
    ko    2022     158     203     196
    nb    2038     142     210     325
    pl    2071     109     163      98
 pt_BR    1806     374     497     166
    sv    1761     419     520     174
 zh_CN    2176       4      21      13
 zh_TW    1740     440     556     236
Permalink | Reply | 0 comments |
headers
vijay | 1 Mar 2011 07:29
Favicon

[PATCH] Compiling subversion trunk with httpd trunk code fails

Hi,

I tried to compile subversion trunk with httpd trunk code. make fails 
with the attached error.

Then I got that there is a macro APLOG_MARK which expands differently in 
httpd-2.2.x and httpd-2.3-dev.

 From httpd-2.2.x,

#define APLOG_MARK __FILE__,__LINE__

 From httpd-2.3-dev,

#define APLOG_MARK __FILE__,__LINE__,APLOG_MODULE_INDEX

The method 
"subversion/mod_authz_svn/mod_authz_svn.c:log_access_verdict()" is being 
called with the argument APLOG_MARK in few places. As it is getting 
expanded to three arguments in httpd-2.3-dev, but the orginal 
implementation of log_access_verdict accepts only two arguments(file and 
line), make fails with "error: too many arguments to function 
‘log_access_verdict’".

Attaching the patch that works for httpd-trunk as well as older versions.

Thanks & Regards,
Vijayaguru
(Continue reading)

Permalink | Reply | 8 comments |
headers
Gavin Beau Baumanis | 1 Mar 2011 09:24

Re: [PATCH] Fix issue #3686 - executable bit not set during merge

Ping. This submission has received no new comments.

On 22/02/2011, at 8:31 AM, Daniel Becroft wrote:

> On Sun, Feb 13, 2011 at 2:15 AM, Daniel Shahaf <d.s <at> daniel.shahaf.name> wrote:
> Daniel Becroft wrote on Sat, Feb 12, 2011 at 08:37:12 +1000:
> >  On Sat, Feb 12, 2011 at 7:31 AM, Daniel Shahaf <d.s <at> daniel.shahaf.name>wrote:
> >
> > > Daniel Becroft wrote on Sat, Feb 12, 2011 at 06:27:31 +1000:
> > > > On Fri, Feb 11, 2011 at 11:26 PM, Daniel Shahaf <d.s <at> daniel.shahaf.name
> > > >wrote:
> > > > > Daniel Becroft wrote on Thu, Feb 10, 2011 at 07:21:30 +1000:
> > > > > >  <at>  <at>  -1118,6 +1120,33  <at>  <at>  merge_binary_file(svn_skel_t **work_items,
> > > > > > +  /* Attempt to merge the binary file. At the moment, we can only
> > > > > > +     handle the special case: if the LEFT side of the merge is equal
> > > > > > +     to WORKING, then we can copy RIGHT directly. */
> > > > >
> > > > > The comment in libsvn_client mentioned two special case, what happened
> > > > > to the other one?  Does the existing wc code already handle it? (I'd be
> > > > > surprised)
> > > > >
> > > > >  -         Alternately, if the 'left' side of the merge doesn't exist
> > > in
> > > > >  -         the repository, and the 'right' side of the merge is
> > > > >  -         identical to the WC, pretend we did the merge (a no-op).
> > > > >
> > > >
> > > > I've been trying to think of a valid scenario for this to occur, but I
> > > can't
> > > > seem to think of one. There's a comment further up:
(Continue reading)

Permalink | Reply | 2 comments |
headers
Philip Martin | 1 Mar 2011 11:38
Favicon

Re: Restarting Apache during a commit through a proxy

Philip Martin <philip.martin <at> wandisco.com> writes:

> I've been thinking about this overnight and I believe I need to do more
> investigation on the WANdisco side.

I now realise I was mistaken about this problem.  The fact that we don't
fsync during a transaction doesn't affect Apache restarts.  When Apache
acknowledges an http request all the file descriptors to the repository
associated with processing that request have been closed and so all data
written has moved from user-space to kernel-space.  The fact that it is
not on disk doesn't matter, it will be visible to other processes.  The
absence of fsync could make a difference is if the machine, rather than
just Apache, were restarted, and I suppose a client/proxy could attempt
one commit that spanned a machine restart, but I'm not going to worry
about it.

The problem that was seen during WANdisco testing occurred when Apache
was restarted after a commit had happened in the repository but before
Apache could acnowledge the http request.  When this happens the
transaction associated with the commit may still exist, or may have been
partially or fully removed.  That's simply normal operation.

--

-- 
Philip
Permalink | Reply | 0 comments |
headers
Philip Martin | 1 Mar 2011 12:16
Favicon

Re: [PATCH] Compiling subversion trunk with httpd trunk code fails

vijay <vijay <at> collab.net> writes:

> 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)
>  <at>  <at>  -32,6 +32,7  <at>  <at> 
>  #include <http_log.h>
>  #include <ap_config.h>
>  #include <ap_provider.h>
> +#include <ap_release.h>
>  #include <apr_uri.h>
>  #include <apr_lib.h>
>  #include <mod_dav.h>
>  <at>  <at>  -519,12 +520,20  <at>  <at> 
>    return OK;
>  }
>  
> +#if AP_SERVER_MAJORVERSION_NUMBER == 2 && AP_SERVER_MINORVERSION_NUMBER == 3

I think this should be ap_mmm.h and AP_MODULE_MAGIC_AT_LEAST.

Perhaps we should be using AP_DECLARE_MODULE or AP_USE_MODULE somewhere
in mod_authz_svn?

> +#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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stefan Sperling | 1 Mar 2011 12:45
Picon

Re: functions that would help TSVN

On Mon, Feb 28, 2011 at 08:35:44PM +0100, Stefan Küng wrote:
> One other thing I'd like to discuss: currently all svn functions use
> streams and provide the data in callbacks to save memory. While I
> fully understand that, I'd like to have at least the
> svn_client_proplist() function to also provide all results in one
> (big) memory hunk. Because right now, to save memory and to avoid
> timeout problems in the callback, svn_client_proplist() does a db
> query for each and every folder and then calls the callback function
> for every folder separately.
> But that is painfully slow if there are hundreds of folders in a
> working copy - one db query for every folder!

This is only true for the BASE tree. For the working tree, we already
use a single query to pull all properties out of the database at once
(see svn_wc__prop_list_recursive, called by svn_client_proplist).
The plan is to use this approach for the BASE tree, too.

> Since most UI clients need all the data in memory anyway, I'd like
> to have a separate svn_client_proplist() API that does *one* db
> query and returns all the results in one go.
> There are several reasons:
> * as mentioned, most UI clients will need all data in memory anyway.
> For example in TSVN I just add the data in the callback to one big
> list/vector/map and start using that data after the function
> returns.

I don't think we need a separate function that does the allocations
on behalf of the callback.
The callback is free to store the data in any way it wants.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Stefan Küng | 1 Mar 2011 13:20
Picon
Gravatar

Re: functions that would help TSVN

On Tue, Mar 1, 2011 at 12:45, Stefan Sperling <stsp <at> elego.de> wrote:
>> Since most UI clients need all the data in memory anyway, I'd like
>> to have a separate svn_client_proplist() API that does *one* db
>> query and returns all the results in one go.
>> There are several reasons:
>> * as mentioned, most UI clients will need all data in memory anyway.
>> For example in TSVN I just add the data in the callback to one big
>> list/vector/map and start using that data after the function
>> returns.
>
> I don't think we need a separate function that does the allocations
> on behalf of the callback.
> The callback is free to store the data in any way it wants.

I'm not requesting such function because I'm lazy and just want svn to
do the work for me. I'm requesting those for performance reasons. Of
course I'm free the store the data any way I want and need in a
callback.
Also I've never said that the current approach doesn't work, I only
mentioned that it's slower than necessary.

Let me illustrate this a little bit:
Assume: 1M properties in 100k folders
svn_proplist recursive.
Callback called 100k times
for every callback:
 - svn lib allocates memory for the data
 - calls callback function, passes data
 - UI client receives the data, copies the data to big memory buffer
 - svn lib deallocates memory for data
(Continue reading)

Permalink | Reply | 1 comment |
headers
Stefan Sperling | 1 Mar 2011 13:37
Picon

Re: functions that would help TSVN

On Tue, Mar 01, 2011 at 01:20:20PM +0100, Stefan Küng wrote:
> Let me illustrate this a little bit:
> Assume: 1M properties in 100k folders
> svn_proplist recursive.
> Callback called 100k times
> for every callback:
>  - svn lib allocates memory for the data
>  - calls callback function, passes data
>  - UI client receives the data, copies the data to big memory buffer
>  - svn lib deallocates memory for data
> 
> memory allocations/deallocations are slow, especially in
> multi-threaded processes (meaning: not big of a problem for the CL
> client but for UI clients).
> In this scenario, there are 100k allocations and deallocations which
> could get reduced to one big allocation and one deallocation.

Oh, I see. If the overhead of copying between buffers hurts performance
that much, we can provide an API that passes a buffer to the application.

It would be interesting to implement this for proplist and then perform
measurements to see if it really makes that much of a difference.
Proplist is just one example where we need to pull data out of the
DB and give it to library callers. I anticipate additional APIs that
use the callback-passing approach in the future, so any insights gained
while experimenting with proplist will help.
Permalink | Reply | 0 comments |
headers
Stefan Sperling | 1 Mar 2011 14:00
Picon

Re: [PATCH] Compiling subversion trunk with httpd trunk code fails

On Tue, Mar 01, 2011 at 11:59:28AM +0530, vijay wrote:
> [[[
> Update log_access_verdict to make it work with httpd trunk as well as older
> versions. The function is being called with APLOG_MACRO 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.
> 
> * subversion/mod_authz_svn/mod_authz_svn.c
>   (log_access_verdict): Modify the signature.

Your log message should probably include this link:
http://httpd.apache.org/docs/trunk/developer/new_api_2_4.html#upgrading_logging

> Patch by: Vijayaguru G <vijay{_AT_}collab.net>
> 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)
>  <at>  <at>  -32,6 +32,7  <at>  <at> 
>  #include <http_log.h>
>  #include <ap_config.h>
>  #include <ap_provider.h>
> +#include <ap_release.h>
>  #include <apr_uri.h>
(Continue reading)

Permalink | Reply | 6 comments |
headers
Stefan Sperling | 1 Mar 2011 14:01
Picon

Re: [PATCH] Fix issue #3686 - executable bit not set during merge

On Tue, Mar 01, 2011 at 07:24:56PM +1100, Gavin Beau Baumanis wrote:
> Ping. This submission has received no new comments.

Thanks for the reminder. Committed in r1075802.
Permalink | Reply | 1 comment |

Gmane