On 10.07.2012 23:40, Julian Foad wrote:
> I think the essence of this line of thought is:
>
> We set up all of the possible mergeinfo scenarios, and we see what 'merge'
> does, and we see what 1.7 'merge --reintegrate' does, and we debate what
> cases are 'supported' versus knowingly 'unsupported
I think the essence of this line of thought is:
We set up all of the possible mergeinfo scenarios, and we see what 'merge'
does, and we see what 1.7 'merge --reintegrate' does, and we debate what cases
are 'supported' versus knowingly 'unsupported', and we see what an ideal
symmetric merge woul
[Mattias Engdegård]
> The biggest surprise was that COW actually made the checkout slightly
> slower, even though no "true" file copies were made. I'm not sure how
> to explain this---perhaps everything is already in cache so the
> copies aren't very expensive, or the COW operations are somehow
>
On Tue, Jul 10, 2012 at 2:43 PM, Robert Muir wrote:
> On Tue, Jul 10, 2012 at 2:17 AM, Trent Nelson wrote:
>>
>> I've also never come across this in the wild. We should definitely ping
>> `rmuir` to find out how he committed that revision; platform, version, etc.
>>
>
> Hi Trent:
> For this comm
9 jul 2012 kl. 18.08 skrev Daniel Shahaf:
Thanks for clarifying. I'm not familiar enough with the library to
have much more to say, but I thought I would point out svn_tristate_t
(cf your maybe_t).
Thank you, I didn't know about svn_tristate_t. I'll be sure to use it
in any production versi
On Tue, Jul 10, 2012 at 6:34 PM, Philip Martin
wrote:
> Stefan Fuhrmann writes:
>
> > On Tue, Jul 10, 2012 at 1:15 PM, Philip Martin
> > wrote:
> >
> >> stef...@apache.org writes:
> >>
> >> > Author: stefan2
> >> > Date: Tue Jul 10 10:19:42 2012
> >> > New Revision: 1359574
> >>
> >> > +e
Stefan Fuhrmann writes:
> On Tue, Jul 10, 2012 at 1:15 PM, Philip Martin
> wrote:
>
>> stef...@apache.org writes:
>>
>> > Author: stefan2
>> > Date: Tue Jul 10 10:19:42 2012
>> > New Revision: 1359574
>>
>> > +else
>> > + right_size += APR_ARRAY_IDX(revprops->sizes, right--,
>> a
/me notes: still unproportionally high N for proplist & propset.
On 2012-07-09 02:50, ne...@apache.org wrote:
> 4K/6K0.68| -0.004 proplist
> 4K/6K0.71| -0.004 propset
signature.asc
Description: OpenPGP digital signature
On Tue, Jul 10, 2012 at 1:15 PM, Philip Martin
wrote:
> stef...@apache.org writes:
>
> > Author: stefan2
> > Date: Tue Jul 10 10:19:42 2012
> > New Revision: 1359574
>
> > +else
> > + right_size += APR_ARRAY_IDX(revprops->sizes, right--,
> apr_off_t);
> > + +
Hi Paul. Thanks for your comments.
Paul Burba wrote:
> On Mon, Jul 9, 2012 at 4:16 PM, Julian Foad wrote:
[...]
>> * The merging history of the root 'R' (the root node of the
>> requested merge source and target trees), and of a subtree 'S' (a
>> single node or subtree
>
> Minor point: I'v
On Tue, Jul 10, 2012 at 3:31 PM, Markus Schaber
wrote:
> Hi, Stefan,
>
> Von: Stefan Fuhrmann [mailto:stefan.fuhrm...@wandisco.com]
> >> What's the performance penalty for modifying a packed rev props? From
> what you've said, it sounds like packing works by fitting as many rev props
> into a 64k
On Tue, Jul 10, 2012 at 4:43 AM, Daniel Shahaf wrote:
> Robert:
>
> How did you commit r1356317? (the import of the api-4_0_0_ALPHA docs to
> the CMS) Did you get any error? Was
> api-4_0_0_ALPHA/org/apache/solr/handler/loader/package-summary.html
> handled specially in some way?
>
> As per the
On Tue, Jul 10, 2012 at 2:17 AM, Trent Nelson wrote:
>
> I've also never come across this in the wild. We should definitely ping
> `rmuir` to find out how he committed that revision; platform, version, etc.
>
Hi Trent:
For this commit, I did a 'cp -r ' of the folder from our release
candidate to
On Mon, Jul 9, 2012 at 4:16 PM, Julian Foad wrote:
> To move forward and decide what behaviour is right, we need to be able to
> compare the 1.7 behaviour with the proposed behaviour in *specific*
> scenarios. So we need to be able to enumerate the specific scenarios that we
> mean by the gene
Hi, Stefan,
Von: Stefan Fuhrmann [mailto:stefan.fuhrm...@wandisco.com]
>> What's the performance penalty for modifying a packed rev props? From what
>> you've said, it sounds like packing works by fitting as many rev props into
>> a 64k chunk, so, let's say I've got a million rev repository. A
stef...@apache.org writes:
> Author: stefan2
> Date: Tue Jul 10 10:19:42 2012
> New Revision: 1359574
> +else
> + right_size += APR_ARRAY_IDX(revprops->sizes, right--, apr_off_t);
> + + SVN_INT64_BUFFER_SIZE;
../src/subversion/libsvn_fs_fs/fs_fs.c: In functi
On Tue, Jul 10, 2012 at 8:09 AM, Trent Nelson wrote:
> Hi Stefan,
>
>
> > This week I had one of my "how hard can it be?" moments
> > and finally implemented revprop packing
>
> Lots of tools, like svnsync, store metadata in r0 rev props. Could this
> rev be excluded from packing?
>
It is exclu
Trent Nelson writes:
> On 7/8/12 11:48 AM, "Daniel Shahaf" wrote:
>
>>Daniel Shahaf wrote on Sat, Jul 07, 2012 at 15:09:38 +0100:
>>> How can we have a 'modify-file' within an added-without-copyfrom tree?
>
> That's a pretty impressive invariant violation. Enversion would have
> caught it, but
Trent Nelson wrote on Mon, Jul 09, 2012 at 23:17:28 -0700:
>
>
> On 7/8/12 11:48 AM, "Daniel Shahaf" wrote:
>
> >Daniel Shahaf wrote on Sat, Jul 07, 2012 at 15:09:38 +0100:
> >> How can we have a 'modify-file' within an added-without-copyfrom tree?
>
> That's a pretty impressive invariant viol
Robert:
How did you commit r1356317? (the import of the api-4_0_0_ALPHA docs to
the CMS) Did you get any error? Was
api-4_0_0_ALPHA/org/apache/solr/handler/loader/package-summary.html
handled specially in some way?
As per the below, that file was committed in a malformed way --- the
metadata c
20 matches
Mail list logo
