Hi,
> Von: Ashod Nakashian [mailto:ashodnakash...@yahoo.com]
>
> >The disadvantage clearly is that we need a few more bits when storing
> that metadata in the SQLite database, instead of in our own file. But in
> my eyes, this few bytes do not outweigh the overhead of inventing our own
> metadata
Hi,
There's an SVN_ERR_ASSERT when reintegrating. From the crash statistics
I get this happens quite often. The stack trace:
libsvn_tsvn!svn_ra_get_location_segments+0x12
libsvn_tsvn!svn_client__repos_location_segments+0x9f
libsvn_tsvn!svn_client_merge4+0xff8
libsvn_tsvn!svn_client_merge4+0x17
On 22.03.2012 17:01, Branko Čibej wrote:
> On 22.03.2012 16:50, Daniel Shahaf wrote:
>> Branko Čibej wrote on Thu, Mar 22, 2012 at 16:37:24 +0100:
>>> It's called SQLite.
>> Heh. I wondered whether I should mention that the server uses BDB to
>> store pristine files. (yes, the situation there is
- Original Message -
> From: Johan Corveleyn
> To: Ashod Nakashian
> Cc: "dev@subversion.apache.org"
> Sent: Monday, March 26, 2012 3:10 AM
> Subject: Re: Compressed Pristines (Simulation)
>
> On Sun, Mar 25, 2012 at 7:17 PM, Ashod Nakashian
> wrote:
> [snip]
>>> From: Hyrum K Wright
- Original Message -
> From: Ivan Zhakov
> To: Ashod Nakashian
> Cc: "dev@subversion.apache.org"
> Sent: Sunday, March 25, 2012 10:55 PM
> Subject: Re: Compressed Pristines (Simulation)
>
> On Sun, Mar 25, 2012 at 21:17, Ashod Nakashian
> wrote:
>> From this output it's clear how mu
>
> From: Greg Stein
>To: Thomas Åkesson
>Cc: Ashod Nakashian ; Subversion Development
>
>Sent: Monday, March 26, 2012 7:42 AM
>Subject: Re: Compressed Pristines (Design Doc)
>
>
>Yeah... optional pristines is orthogonal, and should be considered seperately.
>
Yeah... optional pristines is orthogonal, and should be considered
seperately. It is also a very difficult problem because users of the
various APIs expect the pristine to always be present.
Cheers,
-g
On Mar 25, 2012 7:41 PM, "Thomas Åkesson" wrote:
> Hi Ash,
>
> I noticed that "Remove pristine
Hi,
Sorry about the delay, had a release to sort out...
I have moved the proposal into the wiki:
http://wiki.apache.org/subversion/NonNormalizingUnicodeCompositionAwareness
The comments from Julian and Markus have been implemented and I have added more
information to the "Client Changes" section
/home/neels/svnbench/20120326-002441
Started at Mon Mar 26 00:24:41 UTC 2012
*Disclaimer:* this tests only file://-URL access on a GNU/Linux VM.
This is intended to measure changes in performance of the local working
copy layer, *only*. These results are *not* generally true for everyone.
Average
Hi Ash,
I noticed that "Remove pristine store or render optional" is considered a
Non-Goal. If changes are made to wc-db in order to manage compressed pristines,
it might make sense to ensure that the design can also handle optional
pristines in the future.
The typical Subversion use case (cod
On Sun, Mar 25, 2012 at 7:17 PM, Ashod Nakashian
wrote:
[snip]
>> From: Hyrum K Wright
[snip]
>>In some respects, it looks like you're solving *two* problems:
>>compression and the internal fragmentation due to large FS block
>>sizes. How orthogonal are the problems? Could they be solved
>>inde
On Sun, Mar 25, 2012 at 12:17, Julian Foad wrote:
>...
> Sometimes we have more than two variables because we also want the repository
> root URL, either to check it's the same repo as some other location or to
> derive the repo-root-relative path (or fspath). It's reached the point where
> it
On Sun, Mar 25, 2012 at 13:35, wrote:
>...
> +++ subversion/site/publish/docs/release-notes/1.8.html Sun Mar 25 17:35:32
> 2012
>...
> +was not.) As of 1.7.1 Subversion +href="http://svn.apache.org/viewvc/subversion/branches/1.6.x/subversion/libsvn_fs_fs/fs_fs.c?rev=1303070&r1=1303069&r2=13030
On Sun, Mar 25, 2012 at 09:10, Daniel Shahaf wrote:
> s...@apache.org wrote on Fri, Mar 23, 2012 at 14:38:04 -:
>> +helper script. To run this script, you'll need a Subversion trunk working
>> +copy (or a shallow trunk working copy containing the tools/dist and
>> +build/generator directories)
On 25.03.2012 19:55, Ivan Zhakov wrote:
> On Sun, Mar 25, 2012 at 21:17, Ashod Nakashian
> wrote:
>> From this output it's clear how much waste there is due to internal
>> fragmentation and how much packing helps.
> Working (actual) files are already fragmented due filesystem block
> size. User c
On Sun, Mar 25, 2012 at 13:16, Julian Foad wrote:
> Greg Stein wrote:
>> julianf...@apache.org wrote:
>>> Change the members of 'merge_source_t' from in-line to pointers.
>>> A follow-up to r1303807.
>> This says what you did, but I don't understand the justification for it. The
>> code seems mor
I (Julian Foad) wrote:
> Daniel Shahaf wrote:
>> This revision turned merge_tests.py 127 into XPASS on
>> svn-slik-w2k3-x64-ra. It passes for me too in HEAD.
>>
>> XPASS: merge_tests.py 127: reverse merge applies revs in reverse order
>
> Thanks. It's XPASS for me too; I didn't realize my c
On Sun, Mar 25, 2012 at 21:17, Ashod Nakashian wrote:
> From this output it's clear how much waste there is due to internal
> fragmentation and how much packing helps.
Working (actual) files are already fragmented due filesystem block
size. User can change file system or reduce block size if he ca
(Just changing the subject so mergeinfo gurus spot this thread too.
tldr: #4129 also explains a bug whereby FSFS minfo-cnt values were set
to the value read from uninitialized memory (and which might therefore
have been smaller than the correct value).)
Philip Martin wrote on Fri, Mar 23, 2012 at
All,
Comments and simulation results in-line.
>
> From: Hyrum K Wright
[snip]
>
>So, I've read through the design document, and the various threads,
>and have a couple of comments / questions which I don't think have
>been addressed. My first impression, though
Greg Stein wrote:
> julianf...@apache.org wrote:
>> Change the members of 'merge_source_t' from in-line to pointers.
>> A follow-up to r1303807.
> This says what you did, but I don't understand the justification for it. The
> code seems more complicated now (eg. the create/dup functions).
>??
Go
C. Michael Pilato wrote on Fri, Mar 23, 2012 at 12:21:20 -0400:
> But the benefits to the developers will be noticeable. Currently, the use
> of the various "outsourced" providers is a mess. Every time we want to add
> a new provider, we have to add flavors of it for all the various keyrings
> an
Daniel Shahaf wrote:
> This revision turned merge_tests.py 127 into XPASS on
> svn-slik-w2k3-x64-ra. It passes for me too in HEAD.
>
> XPASS: merge_tests.py 127: reverse merge applies revs in reverse order
Thanks. It's XPASS for me too; I didn't realize my change made it so.
Investigating...
All,
Subversion contains some pretty high level code that's pretty inscrutable. I
keep asking myself how we would do if we were writing in a higher
level or more object-oriented language.
In the merge code we work with coordinates a lot of the time.
Passing these as two separate variables
s...@apache.org wrote on Fri, Mar 23, 2012 at 14:38:04 -:
> +helper script. To run this script, you'll need a Subversion trunk working
> +copy (or a shallow trunk working copy containing the tools/dist and
> +build/generator directories). Run release.py -h to get a
> +list of available subcomma
On Sat, Mar 24, 2012 at 01:17:17PM -0700, Blair Zajac wrote:
> On 03/24/2012 03:13 AM, Stefan Sperling wrote:
> >On Fri, Mar 23, 2012 at 03:54:13PM +0100, Stefan Sperling wrote:
> >>Since this is a 1.6.x release there are -dep tarballs
> >>which should also be signed by those who test them.
> >>I'v
On Sat, Mar 24, 2012 at 07:18:41PM +0200, Daniel Shahaf wrote:
> s...@apache.org wrote on Thu, Mar 22, 2012 at 19:04:19 -:
> > Author: stsp
> > Date: Thu Mar 22 19:04:19 2012
> > New Revision: 1303987
> >
> > URL: http://svn.apache.org/viewvc?rev=1303987&view=rev
> > Log:
> > * tools/dist/dist
27 matches
Mail list logo
