> -Original Message-
> From: danie...@apache.org [mailto:danie...@apache.org]
> Sent: dinsdag 13 september 2011 14:56
> To: comm...@subversion.apache.org
> Subject: svn commit: r1170159 -
> /subversion/trunk/subversion/tests/cmdline/merge_tests.py
>
> Author: danielsh
> Date: Tue Sep 13
On 09/12/2011 09:12 PM, Daniel Shahaf wrote:
> [RFC] In new code, rename RESULT_POOL and SCRATCH_POOL to RESULT and
> SCRATCH, respectively.
>
> Because the names are too long and C is strongly typed.
Meh.
Or, to be more formal about it: -0.
--
C. Michael Pilato
CollabNet <> www.collab.ne
> -Original Message-
> From: C. Michael Pilato [mailto:cmpil...@collab.net]
> Sent: dinsdag 13 september 2011 16:02
> To: Daniel Shahaf
> Cc: dev@subversion.apache.org
> Subject: Re: svn_error_t *make_foo(svn_foo_t **foo_p, apr_pool_t
> *result, apr_pool_t *scratch);
>
> On 09/12/2011 09
Bert Huijben wrote on Tue, Sep 13, 2011 at 16:07:33 +0200:
> I think it hurts readability of patches.
I assumed we'd get used to those names, much like all variables called
'props' are hashes mapping const char * keys to svn_string_t * values,
all variables called 'ffd' are of type fs_fs_data_t *,
On Tue, Sep 13, 2011 at 9:02 AM, C. Michael Pilato wrote:
> On 09/12/2011 09:12 PM, Daniel Shahaf wrote:
>> [RFC] In new code, rename RESULT_POOL and SCRATCH_POOL to RESULT and
>> SCRATCH, respectively.
>>
>> Because the names are too long and C is strongly typed.
>
> Meh.
>
> Or, to be more forma
> On Sat, Sep 10, 2011 at 03:43:36AM +0200, Stefan Sperling wrote:
> > It seems that the elision algorithm is very basic at the moment, which
> > prevents this from being really useful. Subversion only elides
> > mergeinfo which exactly matches the mergeinfo of a parent.
> > It doesn't perform elis
> -Original Message-
> From: hwri...@apache.org [mailto:hwri...@apache.org]
> Sent: dinsdag 13 september 2011 17:08
> To: comm...@subversion.apache.org
> Subject: svn commit: r1170205 -
> /subversion/trunk/subversion/libsvn_client/diff.c
>
> Author: hwright
> Date: Tue Sep 13 15:08:29 20
On Tue, Sep 13, 2011 at 10:17 AM, Bert Huijben wrote:
>
>
>> -Original Message-
>> From: hwri...@apache.org [mailto:hwri...@apache.org]
>> Sent: dinsdag 13 september 2011 17:08
>> To: comm...@subversion.apache.org
>> Subject: svn commit: r1170205 -
>> /subversion/trunk/subversion/libsvn_cl
On Tue, Sep 13, 2011 at 06:02:44AM +0300, Daniel Shahaf wrote:
> The branch doesn't have code for answering questions such as
>
> - where were a given path's parents copied to?
> - when was a given path deleted?
> - (questions about merges)
> - (questions about a directory's properties having cha
On Tue, Sep 13, 2011 at 09:39:11AM -0500, Hyrum K Wright wrote:
> On Tue, Sep 13, 2011 at 9:02 AM, C. Michael Pilato
> wrote:
> > On 09/12/2011 09:12 PM, Daniel Shahaf wrote:
> >> [RFC] In new code, rename RESULT_POOL and SCRATCH_POOL to RESULT and
> >> SCRATCH, respectively.
> >>
> >> Because th
On Tue, Sep 13, 2011 at 11:15:39AM -0400, Bob Archer wrote:
> My question would be will this only elide merge info from child nodes
> that have been modified by the merge in the same way that in 1.7 child
> node merge info is only updated if that child node was a target of the
> merge?
Yes. The m
Stefan Sperling wrote on Tue, Sep 13, 2011 at 19:31:30 +0200:
> On Tue, Sep 13, 2011 at 09:39:11AM -0500, Hyrum K Wright wrote:
> > On Tue, Sep 13, 2011 at 9:02 AM, C. Michael Pilato
> > wrote:
> > > On 09/12/2011 09:12 PM, Daniel Shahaf wrote:
> > >> [RFC] In new code, rename RESULT_POOL and SCR
Does anyone have ideas for how to implement 'upgrade' for the BDB backend?
C. Michael Pilato wrote on Tue, Sep 13, 2011 at 13:52:13 -0400:
> On 09/13/2011 01:28 PM, Stefan Sperling wrote:
> > One other remaining item is in-place upgrades.
> > I'd like to optionally support in-place upgrades instea
In looking over the client diff APIs, I noticed the output parameters
are file handles, not streams. This feels...odd to me, so I hacked
together the attached patch which updates the APIs to use output
streams. It isn't ready to commit just yet, but before doing the
backward compat dance (rev'ing
On 09/13/2011 02:04 PM, Daniel Shahaf wrote:
> Does anyone have ideas for how to implement 'upgrade' for the BDB backend?
The BDB situation should be about the easiest scenario possible. I mean,
it's a database, for crying out loud. My not-completely-thought-out
approach would be: run a cursor
Stefan Sperling wrote on Tue, Sep 13, 2011 at 19:28:01 +0200:
> I'd consider the branch done as soon as both backends store successors
> of each node-revision, and are able to return the list of immediate
> successors of a given node-revision. We must also have some basic unit
> tests to show that
On 09/13/2011 01:28 PM, Stefan Sperling wrote:
> One other remaining item is in-place upgrades.
> I'd like to optionally support in-place upgrades instead of requiring
> users to dump/load.
Yeah, this is a pretty important goal in my book. We've managed to go a
long time without requiring dum
C. Michael Pilato wrote on Tue, Sep 13, 2011 at 14:25:14 -0400:
> On 09/13/2011 02:04 PM, Daniel Shahaf wrote:
> > Does anyone have ideas for how to implement 'upgrade' for the BDB backend?
>
> The BDB situation should be about the easiest scenario possible. I mean,
> it's a database, for crying
On 2011-09-12 22:55, David Darj wrote:
On 2011-09-11 21:40, Johan Corveleyn wrote:
On Mon, Sep 5, 2011 at 11:09 PM, David Darj wrote:
On 2011-09-02 00:02, Johan Corveleyn wrote:
On Tue, Aug 30, 2011 at 11:29 PM, David Darj
wrote:
On 2011-08-28 20:34, Johan Corveleyn wrote:
Hi,
I get a t
On 09/13/2011 02:42 PM, Daniel Shahaf wrote:
> C. Michael Pilato wrote on Tue, Sep 13, 2011 at 14:25:14 -0400:
>> On 09/13/2011 02:04 PM, Daniel Shahaf wrote:
>>> Does anyone have ideas for how to implement 'upgrade' for the BDB backend?
>>
>> The BDB situation should be about the easiest scenario
C. Michael Pilato wrote on Tue, Sep 13, 2011 at 15:02:06 -0400:
> On 09/13/2011 02:42 PM, Daniel Shahaf wrote:
> > C. Michael Pilato wrote on Tue, Sep 13, 2011 at 14:25:14 -0400:
> >> On 09/13/2011 02:04 PM, Daniel Shahaf wrote:
> >>> Does anyone have ideas for how to implement 'upgrade' for the BD
David Darj wrote on Tue, Sep 13, 2011 at 20:55:30 +0200:
> On 2011-09-12 22:55, David Darj wrote:
> >On 2011-09-11 21:40, Johan Corveleyn wrote:
> >>On Mon, Sep 5, 2011 at 11:09 PM, David Darj wrote:
> >>>On 2011-09-02 00:02, Johan Corveleyn wrote:
> On Tue, Aug 30, 2011 at 11:29 PM, David
> >
On Wed, Sep 7, 2011 at 10:52 PM, Daniel Shahaf wrote:
> hwri...@apache.org wrote on Wed, Sep 07, 2011 at 19:36:01 -:
>> @@ -276,6 +345,60 @@ ev2_close_edit(void *edit_baton,
>> apr_pool_t *scratch_pool)
>> {
>> struct ev2_edit_baton *eb = edit_baton;
>> + apr_array_header_
On Sat, Sep 10, 2011 at 3:02 AM, Hyrum K Wright
wrote:
> In accordance with my aforementioned intent, I've rolled 1.7.0-rc3
> from the latest bits on the 1.7.x branch, and posted them here for
> testing / signing:
> http://people.apache.org/~hwright/svn/1.7.0-rc3/
>
> The magic revision is r116735
Only one more *nix sig needed for release. Get yours in now!
-Hyrum
On Fri, Sep 9, 2011 at 8:02 PM, Hyrum K Wright
wrote:
> In accordance with my aforementioned intent, I've rolled 1.7.0-rc3
> from the latest bits on the 1.7.x branch, and posted them here for
> testing / signing:
> http://peopl
On 2011-09-13 21:16, Daniel Shahaf wrote:
David Darj wrote on Tue, Sep 13, 2011 at 20:55:30 +0200:
On 2011-09-12 22:55, David Darj wrote:
On 2011-09-11 21:40, Johan Corveleyn wrote:
On Mon, Sep 5, 2011 at 11:09 PM, David Darj wrote:
On 2011-09-02 00:02, Johan Corveleyn wrote:
On Tue, Aug 3
(about svn_editor_set_props())
hwri...@apache.org wrote on Tue, Sep 13, 2011 at 19:54:14 -:
> Author: hwright
> Date: Tue Sep 13 19:54:14 2011
> New Revision: 1170324
>
> URL: http://svn.apache.org/viewvc?rev=1170324&view=rev
> Log:
> * subversion/include/svn_editor.h
> (svn_editor_set_prop
On phone. Sorry for terse.
On Sep 13, 2011 9:54 AM, wrote:
>
> Author: hwright
> Date: Tue Sep 13 19:54:14 2011
> New Revision: 1170324
>
> URL: http://svn.apache.org/viewvc?rev=1170324&view=rev
> Log:
> * subversion/include/svn_editor.h
> (svn_editor_set_props): Add a couple of notes.
>
> Modif
28 matches
Mail list logo
