vijay wrote:
> This patch updates the CHANGES file to have a note about the new option
> '--drop-all-empty-revs' added to 'svndumpfilter
> include/exclude'.
Thanks. r1451506.
- Julian
Hi,
This patch updates the CHANGES file to have a note about the new option
'--drop-all-empty-revs' added to 'svndumpfilter include/exclude'.
Attached the patch and log message.
Thanks & Regards,
Vijayaguru
* CHANGES: List the new '--drop-all-empty-revs' option to
'svndumpfilter include/ex
Daniel Shahaf wrote on Fri, Mar 01, 2013 at 06:13:54 +0200:
> +1 to commit. The web site will update within a few seconds after your
> commit, so please check then that it still works (and fix or revert if
> not).
BTW, you can check whether the web site has updated by retrieving
http://subversio
Gabriela Gibson wrote on Thu, Feb 28, 2013 at 21:45:10 +:
> On 28/02/13 14:42, C. Michael Pilato wrote:
>> IMO, your log message should explain the reason for and value of such a
>> sweeping change. The diff already tells us what you've done -- developers
>> coming a few years after us will wa
vijay wrote:
> On Wednesday 27 February 2013 10:44 PM, Julian Foad wrote:
>>> + write_out_rev = (! rb->had_dropped_nodes) ? TRUE : FALSE;
>>
>> No, I don't mean that. [...] simply use the boolean "not" operator
>> [...] like this:
>>
>> write_out_rev = ! rb->had_dropped_nodes;
>
> So
Perfect! It ensures that a dev such as myself who isn't closely following
the related discussion threads has a hope of understanding why the change
was made.
On 02/28/2013 04:45 PM, Gabriela Gibson wrote:
> On 28/02/13 14:42, C. Michael Pilato wrote:
>> IMO, your log message should explain the re
Perfect! It ensures that a dev such as myself who isn't closely following
the related discussion threads has a hope of understanding why the change
was made.
On 02/28/2013 04:45 PM, Gabriela Gibson wrote:
> On 28/02/13 14:42, C. Michael Pilato wrote:
>> IMO, your log message should explain the re
On 28/02/13 14:42, C. Michael Pilato wrote:
IMO, your log message should explain the reason for and value of such a
sweeping change. The diff already tells us what you've done -- developers
coming a few years after us will want to know *why* it was done.
How about:
[[[
Update web server config
On 28.02.2013 09:59, Ben Reser wrote:
> On Wed, Feb 27, 2013 at 3:28 PM, Branko Čibej wrote:
>> I propose we do this as follows:
>>
>> * Write a notice about deprecation and what it means in the release notes.
>> * Cause "svnadmin create" to issue a deprecation warning when a new
>> BDB re
> -Original Message-
> From: Julian Foad [mailto:julianf...@btopenworld.com]
> Sent: donderdag 28 februari 2013 20:54
> To: Ben Reser
> Cc: Magnus Thor Torfason; Subversion Development
> Subject: Re: FSFS format7 and compressed XML bundles
>
> Ben Reser wrote:
>
> > Speaking with Julian
On Thu, Feb 28, 2013 at 5:04 PM, Magnus Thor Torfason <
zulutime@gmail.com> wrote:
> Hey all,
>
Sorry that I have to disagree with what most people said.
I guess, Mark got closed to the what the current intend is.
I've been following the discussion about FSFS format7, and had a question:
> I
Ben Reser wrote:
> Speaking with Julian here at ApacheCon he mentioned that gzip has a
> rsyncable option. Looking into this turns out that there is a patch
> applied to Debian's gzip that provides this option. It resets the
> compression algorithm every 1000 bytes and thus makes blocks that can
On Thu, Feb 28, 2013 at 1:45 PM, Ben Reser wrote:
> On Thu, Feb 28, 2013 at 8:28 AM, Mark Phippard wrote:
> > FWIW, the Branch Readme does imply he intends to work on some things that
> > might have an impact here.
>
I pasted the contents of the readme merely to point out that he indicates
that
On Thu, Feb 28, 2013 at 8:37 AM, Ben Reser wrote:
> I just don't see this happening unless someone has a very clever idea
> that I haven't thought of.
Speaking with Julian here at ApacheCon he mentioned that gzip has a
rsyncable option. Looking into this turns out that there is a patch
applied t
On Thu, Feb 28, 2013 at 8:28 AM, Mark Phippard wrote:
> FWIW, the Branch Readme does imply he intends to work on some things that
> might have an impact here. Specifically:
>
> TxDelta v2
> --
>
> Version 1 of txdelta turns out to be limited in its effectiveness for
> larger files when da
On Wed, Feb 27, 2013 at 3:28 PM, Branko Čibej wrote:
> I propose we do this as follows:
>
> * Write a notice about deprecation and what it means in the release notes.
> * Cause "svnadmin create" to issue a deprecation warning when a new
> BDB repository is being created.
> o this doe
On 02/27/2013 06:28 PM, Branko Čibej wrote:
> On 26.02.2013 10:54, C. Michael Pilato wrote:
>> On 02/14/2013 10:23 PM, Branko Čibej wrote:
>>> On 15.02.2013 04:19, Branko Čibej wrote:
>>> and IMHO a resolution to the "deprecate Berkeley DB" discussion.
>> My current thoughts on this can be summariz
On Thu, Feb 28, 2013 at 8:04 AM, Magnus Thor Torfason
wrote:
> I've been following the discussion about FSFS format7, and had a question:
> Is there any chance that the format would improve storage efficiency for
> documents that are stored as compressed (zipped) bundles of XML files and
> other r
On Thu, Feb 28, 2013 at 11:25 AM, Branko Čibej wrote:
> On 28.02.2013 08:04, Magnus Thor Torfason wrote:
> > Hey all,
> >
> > I've been following the discussion about FSFS format7, and had a
> > question: Is there any chance that the format would improve storage
> > efficiency for documents that
On 28.02.2013 08:04, Magnus Thor Torfason wrote:
> Hey all,
>
> I've been following the discussion about FSFS format7, and had a
> question: Is there any chance that the format would improve storage
> efficiency for documents that are stored as compressed (zipped)
> bundles of XML files and other r
Hey all,
I've been following the discussion about FSFS format7, and had a
question: Is there any chance that the format would improve storage
efficiency for documents that are stored as compressed (zipped) bundles
of XML files and other resource files (Read MS Office Documents, but
OpenOffice
IMO, your log message should explain the reason for and value of such a
sweeping change. The diff already tells us what you've done -- developers
coming a few years after us will want to know *why* it was done.
On 02/28/2013 06:31 AM, Gabriela Gibson wrote:
> [[[
> Update web server configuration
[[[
Update web server configuration file and change file permissions to
remove the executable bit.
* site/publish/.htaccess():
remove "XBitHack On".
* site/*
remove svn:executable property from all files, with the
exception of 'download/download.cgi'.
Patch by: Gabriela Gibson
Suggested
On Thu, Feb 28, 2013 at 9:39 AM, Bert Huijben wrote:
> [retry to the right list]
> If you are not going to use these functions I don’t see how this is going
> to help performance. Before this these functions could be inlined in the
> delta code and now they are part of a different library.
>
> Ma
[retry to the right list]
If you are not going to use these functions I don’t see how this is going
to help performance. Before this these functions could be inlined in the
delta code and now they are part of a different library.
Maybe there is no difference if you are compiling a static library w
On Wednesday 27 February 2013 10:44 PM, Julian Foad wrote:
+write_out_rev = (! rb->had_dropped_nodes) ? TRUE : FALSE;
No, I don't mean that. "? TRUE : FALSE" is completely redundant, and I want us
to avoid that sort of redundancy.
"had_nodes_dropped" is a boolean value -- that is, a ye
26 matches
Mail list logo
