On Wed, Apr 24, 2013 at 1:34 AM, Branko Čibej wrote:
> If you consider all this, the easiest approach by far might be to simply
> add a Lucene index of all log messages to the server, then you can and
> any number of bells and whistles including language-specific stemming.
> I'd consider that a
On 25.04.2013 00:34, Bert Huijben wrote:
>
>> -Original Message-
>> From: Bert Huijben [mailto:b...@qqmail.nl]
>> Sent: donderdag 25 april 2013 00:14
>> To: 'Paul Burba'; 'Subversion Development'
>> Subject: RE: svn commit: r1470904 -
>> /subversion/trunk/subversion/libsvn_wc/wc-metadata.sq
Ivan Zhakov wrote on Thu, Apr 25, 2013 at 02:58:05 +0400:
> On Thu, Apr 25, 2013 at 2:01 AM, wrote:
> > +svn_error_t *
> > +subcommand_info(apr_getopt_t *os, void *baton, apr_pool_t *pool)
> > +{
> > + SVN_ERR(svn_cmdline_printf(pool, _("Path: %s\n"),
> > + svn_repos_
On Thu, Apr 25, 2013 at 2:01 AM, wrote:
> URL: http://svn.apache.org/r1471717
> Log:
> Implement 'svnadmin info'.
>
See my review inline.
> Modified:
> subversion/trunk/subversion/svnadmin/svnadmin.c
>
> Modified: subversion/trunk/subversion/svnadmin/svnadmin.c
> URL:
> http://svn.apache.or
> -Original Message-
> From: Bert Huijben [mailto:b...@qqmail.nl]
> Sent: donderdag 25 april 2013 00:14
> To: 'Paul Burba'; 'Subversion Development'
> Subject: RE: svn commit: r1470904 -
> /subversion/trunk/subversion/libsvn_wc/wc-metadata.sql
> > > Which ultimately causes libsvn_wc/upgr
> -Original Message-
> From: Bert Huijben [mailto:b...@qqmail.nl]
> Sent: donderdag 25 april 2013 00:10
> To: 'Paul Burba'; 'Subversion Development'
> Subject: RE: svn commit: r1470904 -
> /subversion/trunk/subversion/libsvn_wc/wc-metadata.sql
>
>
>
> > -Original Message-
> > F
> -Original Message-
> From: Paul Burba [mailto:ptbu...@gmail.com]
> Sent: woensdag 24 april 2013 23:50
> To: Subversion Development
> Cc: Bert Huijben
> Subject: Re: svn commit: r1470904 -
> /subversion/trunk/subversion/libsvn_wc/wc-metadata.sql
>
> On Tue, Apr 23, 2013 at 7:42 AM, wr
On Tue, Apr 23, 2013 at 7:42 AM, wrote:
> Author: rhuijben
> Date: Tue Apr 23 11:42:04 2013
> New Revision: 1470904
>
> URL: http://svn.apache.org/r1470904
> Log:
> * subversion/libsvn_wc/wc-metadata.sql
> (STMT_UPGRADE_31_SELECT_WCROOT_NODES): Replace some ugly SQL with some
> slightly les
On 24.04.2013 17:10, Daniel Shahaf wrote:
> Philip Martin wrote on Wed, Apr 24, 2013 at 16:08:58 +0100:
>> Should we switch to case-sensitive parsing for the rest of the file?
> +1
I'm already working on the svn_config APIs to support case-sensitive
option names as well as section names. Should be
Bo Chen wrote on Wed, Apr 24, 2013 at 12:22:22 -0400:
> File B's initial version B1 is in revision 2, rather than revision 1,
> similarly for file C, whose initial version C1 is in revision 3, rather
> than revision 1. My question is, is there an API in subversion, which can
> find out the revision
Daniel Shahaf wrote on Wed, Apr 24, 2013 at 19:29:35 +0300:
> danie...@apache.org wrote on Wed, Apr 24, 2013 at 16:14:53 -:
> > Author: danielsh
> > Date: Wed Apr 24 16:14:53 2013
> > New Revision: 1471504
> >
> > URL: http://svn.apache.org/r1471504
> > Log:
> > Teach backport.pl to parse non-
danie...@apache.org wrote on Wed, Apr 24, 2013 at 16:14:53 -:
> Author: danielsh
> Date: Wed Apr 24 16:14:53 2013
> New Revision: 1471504
>
> URL: http://svn.apache.org/r1471504
> Log:
> Teach backport.pl to parse non-approved entries, too.
>
> * tools/dist/backport.pl
> (handle_entry): In
I want to use a simple example to describe my question.
Version 1 has 1 file: A1
I change A1 to A2, and add B1, generate revision 2: A2, B1
change A2 to A3, change B1 to B2, add C1, generate revision 3: A3, B2, C1
Change A3 to A4, change B2 to B3, change C1 to C2, generate revision 4: A4,
B3, C
Gabriela Gibson writes:
> Index: subversion/libsvn_subr/config.c
> ===
> --- subversion/libsvn_subr/config.c (revision 1465268)
> +++ subversion/libsvn_subr/config.c (working copy)
> @@ -464,7 +464,7 @@ make_string_from_option(co
Gabriela Gibson wrote:
> [[[
> Fix --internal-diff coredump due to NULL pointer in string routine.
>
> * subversion/libsvn_subr/config.c
> (make_string_from_option): Add test to ensure that the string passed
> to strcmp is not a NULL value.
> ]]]
Thanks, but Ben already fixed that in r14678
[[[
Fix --internal-diff coredump due to NULL pointer in string routine.
* subversion/libsvn_subr/config.c
(make_string_from_option): Add test to ensure that the string passed
to strcmp is not a NULL value.
]]]
Index: subversion/libsvn_subr/config.c
==
I (Julian Foad) wrote on 2013-04-15:
> Mattias Engdegård wrote:
>> If a file has both text and property conflicts, only resolving one of them
>> leads to an incorrect conflict summary message.
>
> I'll take this one. There's a bunch of stuff to sort out, here; marking
> both conflicts as resolv
Blair Zajac wrote on Wed, Apr 24, 2013 at 06:32:39 -0700:
> I think adding a check like that would be good.
>
r1471467, see comments within for a (minor) limitation that introduced.
> I just want to know what did everybody review ;)
Good question.
Philip Martin wrote on Wed, Apr 24, 2013 at 16:08:58 +0100:
> Should we switch to case-sensitive parsing for the rest of the file?
+1
With trunk:
% head -c 1024 /dev/urandom > 1
% $svn ps -F ./1 k ./
property 'k' set on '.'
% $svn diff | perl -lpe 's/[^-~]/%/g'
Index: .
===
--- . (revision 1471438)
+++ . (working copy)
Property changes on: .
Consider an authz file:
[/]
pm = rw
PM = r
When we parse the key=value lines we handle the key case-insensitively
so only one value, the last, gets stored as the second value overrides
the first. However we also store the exact case of the first key and
that is what is checked when quer
I think adding a check like that would be good.
I just want to know what did everybody review ;)
Blair
On Apr 24, 2013, at 6:06 AM, Daniel Shahaf wrote:
> Should backport.pl attempt to catch such a situation?
>
> I'm inclined to say "No", since the entry should not have been moved
> below the
Should backport.pl attempt to catch such a situation?
I'm inclined to say "No", since the entry should not have been moved
below the "Approved" header and given three +1 votes if it had a revnum
typo. (But it should be easy to inject an 'svn log -qvr | wc -l > 4' type
check, if people prefer that
> -Original Message-
> From: MARTIN PHILIP [mailto:codematt...@ntlworld.com] On Behalf Of
> Philip Martin
> Sent: woensdag 24 april 2013 12:44
> To: Bert Huijben
> Cc: 'Branko Čibej'; dev@subversion.apache.org
> Subject: Re: svn commit: r1470936 - in /subversion/trunk/subversion:
> includ
"Bert Huijben" writes:
> Well, explicitly not initializing variables is another way of adding
> undefined behavior.
You are suggesting that all heap variables be explicitly initialised to
zero before being initialised to the correct values. We don't do that
for stack variables, why is it so imp
> -Original Message-
> From: Branko Čibej [mailto:br...@wandisco.com]
> Sent: woensdag 24 april 2013 07:37
> To: dev@subversion.apache.org
> Subject: Re: svn commit: r1470936 - in /subversion/trunk/subversion:
> include/svn_io.h libsvn_subr/stream.c libsvn_wc/adm_ops.c
> libsvn_wc/update_
> -Original Message-
> From: Markus Schaber [mailto:m.scha...@codesys.com]
> Sent: woensdag 24 april 2013 10:24
> To: dev@subversion.apache.org
> Subject: AW: svn commit: r1470936 - in /subversion/trunk/subversion:
> include/svn_io.h libsvn_subr/stream.c libsvn_wc/adm_ops.c
> libsvn_wc/up
Hi,
Von: Branko Čibej [mailto:br...@wandisco.com]
[...]
> >>> I prefer alloc with explicit initialisation unless we know zero is a
> >>> correct initialisation. Adding initialisation to zero makes it
> >>> harder to use a tool like valgrind to identify missing
> initialisations.
> >>>
> >> Ok, bu
Blair Zajac writes:
> It looks like the wrong revision number was given in STATUS, as it's a
> tomcat commit:
>
> http://svn.apache.org/viewvc?view=revision&revision=r1471029
r1471028 is the revision that should have been proposed/voted/merged.
--
Certified & Supported Apache Subversion Downlo
On Tue, 23 Apr 2013, Gabriela Gibson wrote:
Also, a minor design nit (sorry, no code review): The "---f1"
construct is something I've never seen before.
That's why I picked it --- I checked extensively, and no-one
uses a triple dash, so it does exactly what we hope it
will: never interfere wi
30 matches
Mail list logo
