[[[
* subversion/libsvn_repos/load.c
(svn_repos_parse_dumpstream2, svn_repos_parse_dumpstream3): Rename
the older function and add a version_number argument; error out if
there's a version mismatch.
* subversion/include/svn_repos.h
(svn_repos_parse_dumpstream2, svn_repos_parse_dumpstream3)
Hi,
I sent a patch a while ago for svn_repos_parse_dumpstream3. While I
wait for approval, this is an RFC patch describing my future plan once
that patch gets approved. It can be described tersely as "While at it
(adding the new callback), fix everything that's wrong with the
struct". I'm planning
> -Original Message-
> From: Johan Corveleyn [mailto:jcor...@gmail.com]
> Sent: woensdag 18 augustus 2010 15:59
> To: Stefan Fuhrmann
> Cc: Subversion Development
> Subject: Re: Performance branch ready for review
>
> On Wed, Aug 18, 2010 at 9:14 PM, Stefan Fuhrmann
> wrote:
> > Hi @all
> -Original Message-
> From: Stefan Küng [mailto:tortoise...@gmail.com]
> Sent: woensdag 18 augustus 2010 13:37
> To: Bert Huijben
> Cc: 'Hyrum K. Wright'; 'C. Michael Pilato'; 'Subversion Development'
> Subject: Re: svn_client_status5() and depth
> I don't understand: what exactly are
[C. Michael Pilato]
> But, as you said, it's version control -- nothing is ever really lost!
A funny thing to say in a conversation about the obliterate feature.
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
On Wed, Aug 18, 2010 at 05:17:58PM -0700, C. Michael Pilato wrote:
> Thanks for the update, Julian. Great that you were able to make progress at
> all on such a difficult problem; bummer that Reality showed her dark side.
> But, as you said, it's version control -- nothing is ever really lost!
Unt
Thanks for the update, Julian. Great that you were able to make progress at
all on such a difficult problem; bummer that Reality showed her dark side.
But, as you said, it's version control -- nothing is ever really lost!
On 08/18/2010 08:11 AM, Julian Foad wrote:
> On Wed, 2010-08-18, C. Michae
On Wed, Aug 18, 2010 at 16:05, Bert Huijben wrote:
>> -Original Message-
>> From: phi...@apache.org [mailto:phi...@apache.org]
>> Sent: woensdag 18 augustus 2010 12:17
>> To: comm...@subversion.apache.org
>> Subject: svn commit: r986865 - /subversion/trunk/notes/wc-ng/node-data
>>
>> Autho
There was a race condition :) C. Michael Pilato committed the same patch at
the same time as I sent updated version, with less than 3 minutes difference.
Regards,
Alexey.
On Wednesday, August 18, 2010 03:54:43 pm Gavin Beau Baumanis wrote:
> Ping. The renewed patch submission has received no com
On Wed, Aug 18, 2010 at 9:14 PM, Stefan Fuhrmann
wrote:
> Hi @all,
>
> I just finished my porting work; the performance branch
> is now fully synchronized with my prototype code.
> From my point of view, review can start now.
>
> According to my measurements, the code is now faster
> than the orig
Ping. The renewed patch submission has received no comments.
Gavin.
On 12/08/2010, at 6:12 AM, Alexey Neyman wrote:
> On Wednesday, August 11, 2010 12:10:41 pm C. Michael Pilato wrote:
>> On 08/10/2010 09:22 PM, Alexey Neyman wrote:
>>> Okay, try again:
>>>
>>> [[[
>>> Fix the type of struct
On Wed, Aug 18, 2010 at 1:11 AM, wrote:
> Author: stefan2
> Date: Tue Aug 17 23:11:13 2010
> New Revision: 986521
>
> URL: http://svn.apache.org/viewvc?rev=986521&view=rev
> Log:
> Change serialized representation of pointers: instead of storing offsets
> relative to the whole buffer, store the o
Hi Daniel,
Daniel Shahaf writes:
> > - * @since New in 1.1.
> > + * @since New in 2.0.
>
> s/2.0/1.7/
Fixed.
> > +/**
> > + * Similar to svn_repos_parse_dumpstream3(), but is dumpfile version
> > + * agnostic.
> > + *
>
> Perhaps say: "with @a version_number always set to -1" ?
Fixed, along w
Hi Hyrum,
Hyrum K. Wright writes:
> > + * If @a version_number is -1, it is ignored and the dumpstream is
> > + * parsed without this information. If not -1, the function checks the
>
> We try to avoid magic numbers. Is there a #define or constant
> somewhere that you could use? If not, I'd add
Hyrum, Eric H., Philip M. and I met up at WANdisco's office in Sheffield
(England) yeterday and today. One of the things we discussed was
NODE_DATA.
We discussed several sub-topics, of which here are two. I've written
these up including my further thoughts which weren't part of the
discussion, s
Ramkumar Ramachandra wrote on Thu, Aug 19, 2010 at 01:29:02 +0530:
> +++ subversion/include/svn_repos.h(working copy)
> @@ -2661,9 +2665,25 @@ typedef svn_repos_parse_fns2_t svn_repos_parser_fn
> * This is enough knowledge to make it easy on vtable implementors,
> * but still allow expansio
On 18.08.2010 21:58, Bert Huijben wrote:
In libsvn_client/deprecated.c, svn_client_status4() you pass FALSE for
the new sticky param. But that's wrong: in 1.6.x and previous versions,
the depth was always respected/enforced. That's why I noticed the
changed behavior in the first place!
Shouldn't
On Wed, Aug 18, 2010 at 8:59 PM, Ramkumar Ramachandra
wrote:
> [[[
> * subversion/libsvn_repos/load.c
> (svn_repos_parse_dumpstream2, svn_repos_parse_dumpstream3): Rename
> the older function and add a version_number argument; error out if
> there's a version mismatch.
>
> * subversion/include/
On Wed, Aug 18, 2010 at 7:39 PM, Stefan Küng wrote:
> On 17.08.2010 23:41, Hyrum K. Wright wrote:
>>
>> On Tue, Aug 17, 2010 at 3:45 PM, C. Michael Pilato
>> wrote:
>>>
>>> On 08/17/2010 01:42 PM, Stefan Küng wrote:
Maybe I don't understand that change:
--depth specifies a depth to
> -Original Message-
> From: phi...@apache.org [mailto:phi...@apache.org]
> Sent: woensdag 18 augustus 2010 12:17
> To: comm...@subversion.apache.org
> Subject: svn commit: r986865 - /subversion/trunk/notes/wc-ng/node-data
>
> Author: philip
> Date: Wed Aug 18 19:16:59 2010
> New Revisio
[[[
* subversion/libsvn_repos/load.c
(svn_repos_parse_dumpstream2, svn_repos_parse_dumpstream3): Rename
the older function and add a version_number argument; error out if
there's a version mismatch.
* subversion/include/svn_repos.h
(svn_repos_parse_dumpstream2, svn_repos_parse_dumpstream3)
> -Original Message-
> From: Stefan Küng [mailto:tortoise...@gmail.com]
> Sent: woensdag 18 augustus 2010 11:39
> To: Hyrum K. Wright
> Cc: C. Michael Pilato; Bert Huijben; Subversion Development
> Subject: Re: svn_client_status5() and depth
>
> On 17.08.2010 23:41, Hyrum K. Wright wrote
Hi @all,
I just finished my porting work; the performance branch
is now fully synchronized with my prototype code.
From my point of view, review can start now.
According to my measurements, the code is now faster
than the original prototype. Large caches provided, a
single multi-threaded svnserv
Julian Foad wrote:
On Wed, 2010-08-18, Stefan Sperling wrote:
On Tue, Aug 17, 2010 at 11:57:11PM +0200, Stefan Fuhrmann wrote:
I overgeneralized my use-case here: I actually needed "move forward" only.
The concept of "skip N bytes", however, is perfectly in line with
the general
stream
On 17.08.2010 23:41, Hyrum K. Wright wrote:
On Tue, Aug 17, 2010 at 3:45 PM, C. Michael Pilato wrote:
On 08/17/2010 01:42 PM, Stefan Küng wrote:
Maybe I don't understand that change:
--depth specifies a depth to use for the command. If I want the command
to use the depth of the working copy, I
Hyrum K. Wright wrote on Wed, Aug 18, 2010 at 13:18:09 +0100:
> I've added something to the roadmap page which attempts to categorize
> the remaining items for 1.7. It'd be good to include already
> completed items as well, so we don't get too depressed with what left
> (but remember how far we've
On Wed, 2010-08-18, C. Michael Pilato wrote:
> What's the status of obliterate?
Heh. I started down a path that looked promising initially but became
ever more difficult. The parts that are checked in are the easy parts -
hook script support and some ability to remove node-revs from the
reposito
What's the status of obliterate?
I get the sense that it exists in our codebase, for all practical purposes,
in name only. If that's true, and if that's the state it's expected to be
in when 1.7 ships, then I'd really, really like to just see the feature not
ship at all. We don't have to can all
Stefan Fuhrmann wrote on Tue, Aug 17, 2010 at 23:39:37 +0200:
> Daniel Shahaf wrote:
>> stef...@apache.org wrote on Sat, Aug 14, 2010 at 13:20:22 -:
>>> URL: http://svn.apache.org/viewvc?rev=985487&view=rev
>>> +++ subversion/branches/performance/subversion/include/svn_io.h Sat Aug 14
>>> 13:2
Paul Burba wrote on Tue, Aug 17, 2010 at 20:06:34 -0400:
> On Thu, Aug 12, 2010 at 2:51 PM, Daniel Shahaf
> wrote:
> > Paul Burba wrote on Fri, Aug 06, 2010 at 10:30:50 -0400:
> >> As described in issue #2915, in 1.6 when a merge target is a missing
> >> subtree due to its removal by non-svn mean
On Wed, Aug 18, 2010 at 3:16 PM, Daniel Shahaf wrote:
>> atomic-revprop/ r984264 6 days danielsh Tweak the
>> behaviour of a recently-added API to allow conveniently passing errors…
>
> Last touched 6 days ago, so I'm not sure why it's on your list.
Whoops! I've seen thos
> atomic-revprop/ r984264 6 days danielshTweak the
> behaviour of a recently-added API to allow conveniently passing errors…
Last touched 6 days ago, so I'm not sure why it's on your list.
I've discussed the plans on dev@ recently, the only thing blocking it
from moving f
Jack Repenning wrote on Tue, Aug 17, 2010 at 12:09:15 -0700:
>
> On Aug 17, 2010, at 8:28 AM, C. Michael Pilato wrote:
>
> > I've handled this reversion and reworked the text there to make the point
> > that I believe Jack (in his role as a Tigris administrator) was mostly
> > trying to make: "D
On Wed, Aug 18, 2010 at 12:49 PM, Stefan Sperling wrote:
> On Wed, Aug 18, 2010 at 12:59:21AM +0200, Johan Corveleyn wrote:
>> Hi devs,
>>
>> While "Looking to improve performance of svn annotate" [1], I found
>> that the current blame algorithm is mainly client-side bound, and that
>> most of its
On Tue, Aug 17, 2010 at 6:26 PM, C. Michael Pilato wrote:
> On 08/17/2010 09:59 AM, Hyrum K. Wright wrote:
>> Howdy all.
>>
>> All of the wandiscians are having a face-to-face this week, and one of
>> the ideas floated was a public-facing page on our website listing the
>> items left to complete b
On Wed, Aug 18, 2010 at 12:59:21AM +0200, Johan Corveleyn wrote:
> Hi devs,
>
> While "Looking to improve performance of svn annotate" [1], I found
> that the current blame algorithm is mainly client-side bound, and that
> most of its time is spent on "svn diff" (calls to svn_diff_file_diff_2
> fr
On Wed, 2010-08-18, Stefan Sperling wrote:
> On Tue, Aug 17, 2010 at 11:57:11PM +0200, Stefan Fuhrmann wrote:
> > I overgeneralized my use-case here: I actually needed "move forward" only.
> > The concept of "skip N bytes", however, is perfectly in line with
> > the general
> > stream semantics. Be
On Wed, Aug 18, 2010 at 11:31 AM, Stefan Sperling wrote:
> On Tue, Aug 17, 2010 at 05:33:13PM -0500, Hyrum K. Wright wrote:
>> It's that time again! In looking at the list of current branches
>> (excepting release and backport branches I've noticed several which
>> look to be abandoned or unmaint
On Tue, Aug 17, 2010 at 05:33:13PM -0500, Hyrum K. Wright wrote:
> It's that time again! In looking at the list of current branches
> (excepting release and backport branches I've noticed several which
> look to be abandoned or unmaintained. Branches which have not been
> touched in over a year i
On Tue, Aug 17, 2010 at 11:57:11PM +0200, Stefan Fuhrmann wrote:
> I overgeneralized my use-case here: I actually needed "move forward" only.
> The concept of "skip N bytes", however, is perfectly in line with
> the general
> stream semantics. Because this also fits my needs, I changed the API in
>
40 matches
Mail list logo
