On 13.02.2011 17:44, Daniel Shahaf wrote:
> Branko Čibej wrote on Sun, Feb 13, 2011 at 16:10:03 +0100:
>> On 13.02.2011 09:33, Daniel Shahaf wrote:
>>>> +strncpy(orig_lc_all, setlocale(LC_ALL, NULL), sizeof orig_lc_all);
>>> sizeof() with parens please.
>> W
On 13.02.2011 21:28, Bert Huijben wrote:
>
>> -Original Message-
>> From: Danny Trebbien [mailto:dtrebb...@gmail.com]
>> Sent: zondag 13 februari 2011 21:00
>> To: Subversion Development
>> Subject: [PATCH] extend the SVN_ERR macro with a cleanup statement
>> parameter
>>
>> Attached is a s
On 13.02.2011 20:15, Danny Trebbien wrote:
> I also try the Windows-specific locale strings first because I know
> that a Linux system successfully ignores them.
Does setlocale even have a real effect on Windows? Last time I looked,
you couldn't change the per-process locale.
-- Brane
On 14.02.2011 13:37, Stefan Sperling wrote:
> On Tue, Feb 08, 2011 at 11:50:36PM +0100, Branko Čibej wrote:
>> Well, here it is, I fixed the thinko in the actual_props query and got
>> all prop_tests to pass with this version.
> Just FYI, the patch doesn't apply to HEAD. I&#
On 15.02.2011 01:42, Johan Corveleyn wrote:
> 2) Faster hash function for hashing lines. [ Quick win ]
>
> - Currently, we use adler32 (after the line has been normalized).
>
> - GNU diff uses some simple bit shifting scheme, which seems to be a
> lot faster (maybe it has more hash-collisions, but
On 15.02.2011 13:04, Johan Corveleyn wrote:
>> In other news, why do we need our own hash function anyway? Or our own
>> table or tree or whatever? NIH syndrome?
> No idea, really. I'm probably not the guy you're expecting an answer
> from :-), but:
> - apr_hashfunc_default could be very useful her
On 16.02.2011 11:52, Philip Martin wrote:
> Stefan Sperling writes:
>
>> [[[
>> Improve performance of svn proplist in a similar way as was done in r1039808.
>> But, this time, avoid problems with callbacks invoked during sqlite
>> transactions by storing results in a temporary table and invoking
On 16.02.2011 13:06, Daniel Shahaf wrote:
> Julian Foad wrote on Tue, Feb 15, 2011 at 15:06:43 +:
>> * * This specification is conceptually simple, but requires completing disk
>> * operations within SDB transactions, which may make it too inefficient
>> * in practice. An alternative sp
On 16.02.2011 19:25, Julian Foad wrote:
> On Tue, 2011-02-15, Stefan Sperling wrote:
>> [[[
>> Improve performance of svn proplist in a similar way as was done in r1039808.
>> But, this time, avoid problems with callbacks invoked during sqlite
>> transactions by storing results in a temporary table
On 16.02.2011 20:26, Mark Phippard wrote:
> 2011/2/16 Branko Čibej :
>
>> My not very humble opinion -- we can play silly buggers trying to
>> optimize this bit of the query, but effort would be better spent in
>> merging NODES and ACTUAL_NODE, which in turn would allow
On 16.02.2011 23:15, Philip Martin wrote:
> Blair Zajac writes:
>
>> On 02/16/2011 08:44 AM, Philip Martin wrote:
>>> So if the timing is just right it's possible for one Apache process to
>>> start writing the transaction, for that process to stop, and for another
>>> process to take over the com
On 16.02.2011 23:56, Blair Zajac wrote:
> On 02/16/2011 02:15 PM, Philip Martin wrote:
>> Blair Zajac writes:
>>
>>> On 02/16/2011 08:44 AM, Philip Martin wrote:
So if the timing is just right it's possible for one Apache process to
start writing the transaction, for that process to stop
On 17.02.2011 00:13, Philip Martin wrote:
> Branko Čibej writes:
>
>> In other words, use a proper crash-resistant transaction commit
>> sequence, with automatic rollback as necessary. See the sqlite docs for
>> a description of one way of doing this. :)
> Possibly. B
On 17.02.2011 12:47, Stefan Küng wrote:
> Hi,
>
> The new function svn_wc__prop_list_recursive() provides a big
> performance gain for listing all properties of a full working copy.
> Currently I have to use svn_client_proplist3() to make use of that.
>
> But I'd like to have that API accessible di
On 17.02.2011 13:39, Julian Foad wrote:
> Let me point out the background, in case you weren't aware. There has
> been a general feeling (especially during the WC re-write) that the WC
> API wasn't well suited to being maintained as a public API and that we
> should move in the direction of provid
On 17.02.2011 14:12, Stefan Sperling wrote:
> On Thu, Feb 17, 2011 at 01:52:44PM +0100, Branko Čibej wrote:
>> On 17.02.2011 13:39, Julian Foad wrote:
>>> Let me point out the background, in case you weren't aware. There has
>>> been a general feeling (especially
On 17.02.2011 21:43, Mark Phippard wrote:
> On Thu, Feb 17, 2011 at 3:35 PM, Ivan Zhakov wrote:
>
>> I'm looking to memory usage issues in svn update/export/switch in
>> ra_serf. And I come to question: what is the rationale of using
>> 'skelta' update REPORT mode, and then sending many GETs/PROPF
On 18.02.2011 15:49, Julian Foad wrote:
> svn_error_t *
> +svn_sqlite__with_immediate_transaction(svn_sqlite__db_t *db,
> + svn_sqlite__transaction_callback_t cb_func,
> + void *cb_baton,
> + apr_pool_t *scratch_pool /* NULL allowed */)
> +{
So you created a new (private) function that's a copy-pa
On 18.02.2011 16:51, Julian Foad wrote:
> On Fri, 2011-02-18 at 16:01 +0100, Branko Čibej wrote:
>> On 18.02.2011 15:49, Julian Foad wrote:
>>> svn_error_t *
>>> +svn_sqlite__with_immediate_transaction(svn_sqlite__db_t *db,
>>> + svn_sqlite__transaction_call
On 20.02.2011 22:05, Daniel Becroft wrote:
> ...
> /subversion/libsvn_fs_fs/.libs/libsvn_fs_fs-1.so.0: undefined
> reference to `svn_temp_serializer__add_string'
> collect2: ld returned 1 exit status
>
> I've narrowed it down to r1072302, and if I update back to -1, everything
> builds correctly. I
On 21.02.2011 11:20, Philip Martin wrote:
> Noorul Islam K M writes:
>
>> I think we have in consistent python indentation. I can see that we use
>> 2 space in test/ and 4 in bindings/ctypes-python. Is it not a good idea
>> to stick to common indentation? I can fix it. Fixing ctypes-python
>> wi
On 21.02.2011 11:32, Noorul Islam K M wrote:
> Noorul Islam K M writes:
>
>> Stefan Sperling writes:
>>
>>> On Mon, Feb 21, 2011 at 01:44:35PM +0530, Noorul Islam K M wrote:
>>>
This patch reduces checkout by around 23 times.
>>> On my system the difference is 43 seconds vs. 30 seconds.
>>>
On 21.02.2011 12:04, Philip Martin wrote:
> Stefan Sperling writes:
>
>> On Mon, Feb 21, 2011 at 01:44:35PM +0530, Noorul Islam K M wrote:
>>> This patch reduces checkout by around 23 times.
>> On my system the difference is 43 seconds vs. 30 seconds.
> On my low-end Linux desktop it's 7.5 seconds
On 21.02.2011 13:12, Philip Martin wrote:
> Branko Čibej writes:
>
>> We should not be optimising tests for performance over clarity, ever. In
>> other words -- don't combine them. Anyone who has trouble with tests
>> taking too long can use a RAMdisk, --bdb-tx
On 21.02.2011 23:55, Blair Zajac wrote:
> On 2/9/11 10:30 AM, Blair Zajac wrote:
>> On 2/9/11 1:38 AM, John Szakmeister wrote:
>>> On Mon, Feb 7, 2011 at 4:26 PM, Blair Zajac wrote:
[I sent this to d...@apr.apache.org but haven't received a response.
Thread
here:
http://mail-arc
On 22.02.2011 02:50, Noorul Islam K M wrote:
> danie...@apache.org writes:
>
>> Author: danielsh
>> Date: Mon Feb 21 18:14:02 2011
>> New Revision: 1073102
>>
>> URL: http://svn.apache.org/viewvc?rev=1073102&view=rev
>> Log:
>> * subversion/include/private/svn_debug.h
>> (SVN_DBG): Merge docstrin
On 22.02.2011 18:17, Julian Foad wrote:
>> Proposed Support Library
>>
>>
>>Assumptions
>>---
>>
>>The main assumption is that we'll keep using APR for character set
> s/character set/character encoding/.
>
>>conversion, meaning that the recoding sol
On 22.02.2011 20:11, Daniel Shahaf wrote:
> Branko Čibej wrote on Tue, Feb 22, 2011 at 19:41:12 +0100:
>> On 22.02.2011 18:17, Julian Foad wrote:
>>> For example, a solution that involves normalizing all input to NFD would
>>> have the advantages that on MacOSX it would
So is this a problem with the APR build, or with Subversion? It sure
looks like an APR issue to me.
On 24.02.2011 08:53, Marc Haesen wrote:
> Hi,
>
>
>
> I saw a crash when running svn blame with a svn.exe compiled for win64
> on trunk.
>
> After some investigation I found the reason for the cra
On 24.02.2011 11:45, Johan Corveleyn wrote:
> - Maybe intra-repos externals would benifit from a new name, e.g.
> "internals" ;-)?
Symbolic links. :) Except that the name is already taken.
-- Brane
On 24.02.2011 18:03, Julian Foad wrote:
> On Wed, 2011-02-23, Daniel Shahaf wrote:
>> julianf...@apache.org wrote on Tue, Feb 22, 2011 at 15:38:35 -:
>>> Modified: subversion/trunk/subversion/libsvn_wc/wc_db_pristine.c
>>> URL:
>>> http://svn.apache.org/viewvc/subversion/trunk/subversion/libsv
On 25.02.2011 16:53, Julian Foad wrote:
> On Thu, 2011-02-24, Branko Čibej wrote:
>> On 24.02.2011 18:03, Julian Foad wrote:
>>> On Wed, 2011-02-23, Daniel Shahaf wrote:
>>>> julianf...@apache.org wrote on Tue, Feb 22, 2011 at 15:38:35 -:
>>>>> +/
On 26.02.2011 07:32, Ivan Zhakov wrote:
> 2011/2/26 Branko Čibej :
>> On 25.02.2011 16:53, Julian Foad wrote:
>>> On Thu, 2011-02-24, Branko Čibej wrote:
>>>> On 24.02.2011 18:03, Julian Foad wrote:
>>>>> On Wed, 2011-02-23, Daniel Shahaf wrote:
>
On 26.02.2011 02:23, Branko Čibej wrote:
> ... but my last battle with Windows filesystem internals was
> more than 10 years ago.
(I lost)
On 26.02.2011 10:50, Ivan Zhakov wrote:
> 2011/2/26 Branko Čibej :
>> On 26.02.2011 07:32, Ivan Zhakov wrote:
>>> Problem of re-installing file over marked for deletion file can be
>>> solved using the following trick:
>>> 1. Rename file to temporary name.
>
On 26.02.2011 12:36, Paolo Di Pietro wrote:
> Hi all,
>
> I just downloaded latest x64 version and try to installi it on my win 7 x64
> running on a wmvare workstation.
>
> TortoiseSVN 1.6.12, Build 20536 - 64 Bit , 2010/11/24 20:59:01
> Subversion 1.6.15,
> apr 1.3.8
> apr-utils 1.3.9
> neon 0.
On 26.02.2011 20:40, Ivan Zhakov wrote:
> Btw I think it makes sense rename file to tmp directory in working
> copy instead of pristines directory, since it could be crash/failure
> between rename and delete. In this case pristines directory will
> polluted with orphaned pristines.
That works as l
On 03.03.2011 17:33, Philip Martin wrote:
> Greg Stein writes:
>
>> On Thu, Mar 3, 2011 at 10:35, Hyrum K Wright wrote:
>>> On Thu, Mar 3, 2011 at 9:03 AM, wrote:
Author: philip
Date: Thu Mar 3 15:03:42 2011
New Revision: 1076645
URL: http://svn.apache.org/viewvc?rev=1
On 04.03.2011 16:33, hwri...@apache.org wrote:
> Author: hwright
> Date: Fri Mar 4 15:33:48 2011
> New Revision: 1078008
>
>
> - scb.changelist = changelist;
> -
> - SVN_ERR(with_db_txn(wcroot, local_relpath, set_changelist_txn, &scb,
> - scratch_pool));
> + SVN_ERR(with_
On 05.03.2011 11:34, Stefan Fuhrmann wrote:
> I suspect that -fstrict-aliasing (or something similar)
> might have broken svn_temp_deserializer__resolve().
>
> r1078256 tries to circumvent that.
Ahem. Type casting will not help, at least GCC's optimizer sees right
through them. The thing to do is
On 05.03.2011 19:52, Stefan Fuhrmann wrote:
> On 05.03.2011 11:55, Branko Čibej wrote:
>> On 05.03.2011 11:34, Stefan Fuhrmann wrote:
>>> I suspect that -fstrict-aliasing (or something similar)
>>> might have broken svn_temp_deserializer__resolve().
>>>
&
On 06.03.2011 11:12, Avalon wrote:
> Hi,
>
> i am using the svn log command with a "forward" revision range, e.g.
> "-r N:HEAD".
> This fails if the requested path has been deleted in HEAD revision.
>
> When used with "backward" ranges, which are commonly used, e.g. "-r
> N:1", the result is ok - e
On 11.03.2011 12:05, Greg Stein wrote:
> This is a great simplification, but it makes me wonder... how did that
> original version even get conceived?
Looks like someone took a hint my NODES_CURRENT view but didn't
understand why it was more complicated than this one. :)
-- Brane
Jack Repenning wrote:
> On Jan 4, 2010, at 5:48 AM, Mark Phippard wrote:
>
>> Could we just declare that the paths are passed as UTF-8 strings?
>
> Any chance of declaring that the paths are not only UTF-8, but also
> *composed* UTF-8?
That's an even bigger can of worms; we don't even guarantee th
Mark Mielke wrote:
> The model is a bit easier to implement in ClearCase and GIT, since
> these are both effectively the working copy is a different stream from
> the parent whereas Subversion designer work flows tend to work
> directly on "trunk".
In both ClearCase and GIT (and more so in ClearCa
C. Michael Pilato wrote:
> Sure. Ideally, the client would be able to say, "I had trouble parsing the
> XML in the response, namely this bit here: asdf"
>
> Wanna dive in and look into a patch?
>
Actually the svn: in property names should never have been
interpreted as an XML namespace n
Mark Mielke wrote:
> On 01/07/2010 04:42 AM, Branko Čibej wrote:
>> Mark Mielke wrote:
>>
>>> The model is a bit easier to implement in ClearCase and GIT, since
>>> these are both effectively the working copy is a different stream from
>>> the parent w
Mark Mielke wrote:
> On 01/07/2010 02:11 PM, Branko Čibej wrote:
>> Mark Mielke wrote:
>>
>>> On 01/07/2010 04:42 AM, Branko Čibej wrote:
>>>
>>>> Mark Mielke wrote:
>>>>
>>>>
>>>>> The model is a
Greg Hudson wrote:
> On Fri, 2010-01-08 at 15:31 -0500, Paul Querna wrote:
>
>> "Profile everything, be faster at everything"
>>
>
> There are smart people who will disagree with me on this, but I'm not
> sure the best tool for improving Subversion performance is a profiler.
> Historically
Mark Phippard wrote:
> On Fri, Jan 8, 2010 at 3:55 PM, Hyrum K. Wright
> wrote:
>
>> We need a website at subversion.apache.org. We've put up some placeholder
>> pages, and I recently
>> started playing with an Anakia-generated site in it's place. I've come
>> across a few questions, and th
Hyrum K. Wright wrote:
> On Jan 14, 2010, at 6:33 AM, Mark Phippard wrote:
>
>
>> On Wed, Jan 13, 2010 at 11:19 AM, Hyrum K. Wright
>> wrote:
>>
>>
>>> Given this feedback, and the fact that it's a patch release with supposed
>>> minimal changes between releases, I agree we should
>>> ste
William A. Rowe Jr. wrote:
> On 1/19/2010 5:19 AM, Bert Huijben wrote:
>
>> The patch was written on the 1.4.x branch but I svn switch'ed it to trunk
>> for easy application.
>>
>
> I would suggest one bit of alternate code that is a bit more condensed, any
> concern?;
>
> +static int same
Justin Erenkrantz wrote:
> On Fri, Jan 29, 2010 at 6:37 AM, C. Michael Pilato
> wrote:
>
>> Dongsheng Song wrote:
>>
>>> 1. website format
>>>
>>> I suggest use xml format, we can select docbook website like NetBSD[1], or
>>> custom xml format like httpd[2].
>>>
>> We already decid
Hyrum K. Wright wrote:
> There's an Apache Retreat in Ireland in April:
> http://apache.eventbrite.com/
>
> I'm tempted to go, if only so I can get interaction with a large-ish number
> of Subversion users. Is anybody else planning on attending?
>
Tickets booked.
-- Brane
Hyrum K. Wright wrote:
> Just going through the svnj source, and I started wondering why we're not
> using generics in our own java packages. Generics were introduced in Java
> 5.0, but turns out that we only require 1.3 in our own source. Given that
> 5.0 was introduced in 2004, isn't it abou
On 30.03.2010 19:35, Hyrum K. Wright wrote:
> On Mar 30, 2010, at 12:34 PM, Justin Erenkrantz wrote:
>
>
>> On Mon, Mar 29, 2010 at 4:42 PM, C. Michael Pilato
>> wrote:
>>
>>> Hey, devs. As many of you know, a group of us met in NYC last week to talk
>>> about Subversion's direction and
On 05.04.2010 17:06, Stefan Sperling wrote:
> An idea we're playing with to mitigate this problem is having designated
> properties in the svn: namespace which allow users to tell svn what their
> branching/merging strategy is.
(Thereby making things even more flexible, complex, and error-prone.)
On 06.04.2010 12:18, Stefan Sperling wrote:
> On Tue, Apr 06, 2010 at 07:04:42AM +0200, Branko Čibej wrote:
>
>> On 05.04.2010 17:06, Stefan Sperling wrote:
>>
>>> An idea we're playing with to mitigate this problem is having designated
>>> pro
Johan Corveleyn wrote:
> Hi all,
>
> Sorry it took a while to respond (been away for a while). I've been
> thinking a little about this, looking at the code ...
>
> I see 3 options:
>
> 1) Determine the max length of revnum (and author) in blame.c, either
> while building the blame chunks or in an
On 23.04.2010 11:45, Bert Huijben wrote:
>> -Original Message-
>> From: Greg Stein [mailto:gst...@gmail.com]
>> Sent: vrijdag 23 april 2010 0:57
>> To: Hyrum K. Wright
>> Cc: Subversion Development
>> Subject: Re: Feature idea: user-configurable post-commit notifications
>>
>> Write a hook
On 03.05.2010 23:05, Stefan Fuhrmann wrote:
> Blair Zajac wrote:
>> On 5/2/10 8:56 AM, Philipp Marek wrote:
>>> Hello Stefan!
>>>
The idea is the following: ra_local (and possibly others)
are "reliable" in that they won't corrupt transmission.
For now, this implies that we don't need
On 21.05.2010 23:18, Greg Ames wrote:
> The current svn_ctype_* implementation depends on ASCII character
> encoding. APR's ctype functions are portable, so use those on EBCDIC
> systems.
>
> A somewhat surprising side effect is that svn messages become mostly
> readable on z/OS with the help of s
On 24.05.2010 20:10, Greg Ames wrote:
> On Sun, May 23, 2010 at 5:40 PM, Branko Čibej <mailto:br...@xbc.nu>> wrote:
>
>
> This is very, very wrong, because we use the ctypes for other things,
> not just for string literals.
>
>
> I'm aware that ctyp
On 25.06.2010 10:28, Daniel Shahaf wrote:
> In the meantime I discovered that 'uudecode -p' extracts the attachments
> from the /^begin/../^end/ lines.
>
> I learnt something new today...
>
> Daniel
> (and it's not noon yet!)
>
Then it's time to continue your education and start sending shar fi
On 02.07.2010 13:39, Mark Phippard wrote:
> There is a common problem people have where they get weird performance
> spikes like this. It is caused by the server not having enough
> entropy and some code on the server that generates a random number
> takes forever.
>
> Go here: http://svn.haxx.se
On 02.07.2010 14:14, Daniel Shahaf wrote:
> Edward Ned Harvey wrote on Fri, 2 Jul 2010 at 07:42 -0400:
>
>> We first experienced the problem in production. Clients connecting via
>> svn:// to svnserver.
>>
>> Since I'm debugging, I'm able to reproduce it on the command line with svn,
>> using s
On 28.07.2010 21:55, Daniel Shahaf wrote:
> Stefan Sperling wrote on Wed, Jul 28, 2010 at 16:05:49 +0200:
>
>> But there's no harm in making svn patch interpret existing move information
>> in git diffs. We can carry out a corresponding copy + delete.
>> We won't be generating move git diff head
On 28.07.2010 12:06, Daniel Näslund wrote:
> * base85 encode binary content
>
Does git do that? Hmmm ... I'd have used base64 myself, not quite as
compact but a lot more existing tools and libraries understand it.
-- Brane
On 07.07.2010 18:29, Greg Hudson wrote:
> On Wed, 2010-07-07 at 11:44 -0400, Marco Jansen wrote:
>
>> So therefor, what we would like to see is to be able to have a transparent
>> branch: One which fetches updates from both branch and trunk, without having
>> them listed as changes or triggering
On 30.07.2010 03:21, C. Michael Pilato wrote:
> On 07/29/2010 08:54 PM, Mike Dixon wrote:
>
>> On 7/29/2010 9:43 AM, C. Michael Pilato wrote:
>>
>>> On 07/29/2010 12:28 PM, Mark Phippard wrote:
>>>
If we just do the redirects, might a user just not perceive SVN as
being slo
On 30.07.2010 13:57, C. Michael Pilato wrote:
> On 07/30/2010 03:55 AM, Branko Čibej wrote:
>
>> That approach just doesn't sound right to me. I've always understood
>> that a temporary redirect implies that requests should always try the
>> original first. Sin
On 04.08.2010 12:14, Julian Foad wrote:
> On Tue, 2010-08-03 at 20:08 +0300, Daniel Shahaf wrote:
>
>> Julian Foad wrote on Tue, Aug 03, 2010 at 17:36:00 +0100:
>>
>>> On Tue, 2010-08-03 at 18:19 +0300, Daniel Shahaf wrote:
>>>
Daniel Shahaf wrote on Tue, Aug 03, 2010 at 11:58:3
I have to agree. While it may make sense to be able create a dumpfile of
a remote repository, I'm not so sure that /loading/ a dumpfile remotely
is sensible. And it's the load that potentially requires a UUID change.
-- Brane
On 06.08.2010 16:03, Greg Stein wrote:
> Back up here.
>
> Why would an
On 06.08.2010 16:30, Hyrum K. Wright wrote:
> On Fri, Aug 6, 2010 at 9:24 AM, Greg Stein wrote:
>
>> On Fri, Aug 6, 2010 at 10:15, Ramkumar Ramachandra
>> wrote:
>>
>>> Hi Greg,
>>>
>>> Greg Stein writes:
>>>
Why would an admin install a hook to allow changing a UUID? Why wou
On 06.08.2010 19:26, Justin Erenkrantz wrote:
> On Fri, Aug 6, 2010 at 7:34 AM, Branko Čibej wrote:
>
>> Ahem. You guys have forgotten about Justin's RW-master/RO-slave
>> replication hack, which *requires* the slave repositories to have the
>> same UUID as the ma
On 06.08.2010 20:13, Greg Hudson wrote:
> On Fri, 2010-08-06 at 13:50 -0400, Hyrum K. Wright wrote:
>
>> I'm doing some more thinking about repository-dictated configuration,
>>
> I get nervous when I see people talk about repository-dictated
> configuration as an extension of the general c
On 06.08.2010 20:18, Hyrum K. Wright wrote:
> On Fri, Aug 6, 2010 at 1:13 PM, Greg Hudson wrote:
>
>> On Fri, 2010-08-06 at 13:50 -0400, Hyrum K. Wright wrote:
>>
>>> I'm doing some more thinking about repository-dictated configuration,
>>>
>> I get nervous when I see people talk ab
On 07.08.2010 16:32, Ramkumar Ramachandra wrote:
> Hi Daniel,
>
> Daniel Shahaf writes:
>
>> artag...@apache.org wrote on Sat, Aug 07, 2010 at 12:31:50 -:
>>
>>> Author: artagnon
>>> Date: Sat Aug 7 12:31:50 2010
>>> New Revision: 983222
>>>
>>> URL: http://svn.apache.org/viewvc?rev=98
On 23.06.2012 00:23, Vincent Lefevre wrote:
> Thanks for the explanations.
>
> On 2012-06-22 00:18:50 +0200, Stefan Fuhrmann wrote:
>> xdelta uses fixed-size 100kByte deltification windows.
>> The Changelog file in question is >400k, i.e. 4+ windows.
>> You insert about 2k at the beginning of the f
On 28.06.2012 01:32, Greg Stein wrote:
> On Wed, Jun 27, 2012 at 7:19 PM, Johan Corveleyn wrote:
>> On Tue, Jun 26, 2012 at 10:51 AM, Stefan Sperling wrote:
>>> On Mon, Jun 25, 2012 at 07:51:59PM -0400, Greg Stein wrote:
>> ...
>>> I would prefer to by default keep working copy upgrades manual fr
On 28.06.2012 05:24, Hyrum K Wright wrote:
> On Wed, Jun 27, 2012 at 9:13 PM, Branko Čibej
> wrote:
>> On 28.06.2012 01:32, Greg Stein wrote:
>>> On Wed, Jun 27, 2012 at 7:19 PM, Johan Corveleyn wrote:
>>>> On Tue, Jun 26, 2012 at 10:51 AM, Stefan Sperling wro
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
On 11.07.2012 12:44, Julian Foad wrote:
> Branko Čibej wrote:
>> Am I correct in assuming that most of this discussion is a consequence
>> of the current implementation of mergeinfo inheritance? I.e., that there
>> are a certain number of hoops one needs to jump through in
On 11.07.2012 13:43, Johan Corveleyn wrote:
> On Sun, Jun 24, 2012 at 3:51 PM, Julian Foad
> wrote:
> ...
>> I just want to say: I'm not at all demanding we break backward
>> compatibility. Sorry if it sounded like it. I'm just saying that we're
>> proposing to change the behaviour of the plain
On 12.07.2012 18:31, Peter Samuelson wrote:
> [Markus Schaber]
>> So my personal experience tells me that multiple-client scenarios are
>> the common case, and that the deployment strategy (only using linux
>> distro packages, or 3-in-1 bundles like VisualSVN) can reduce that
>> problem.
> So, we p
On 12.07.2012 21:20, Peter Samuelson wrote:
> Reposting under a new thread + subject line, at Daniel's suggestion.
>
> [Markus Schaber]
>> So my personal experience tells me that multiple-client scenarios are
>> the common case, and that the deployment strategy (only using linux
>> distro packages,
On 13.07.2012 12:40, Hyrum K Wright wrote:
> On Fri, Jul 13, 2012 at 5:32 AM, Branko Čibej wrote:
>> ...
>> And really, there's no reason why the Subversion command-line client
>> shouldn't do the same thing -- in fact, this is by far the easiest way
>> to
On 13.07.2012 17:21, Peter Samuelson wrote:
> [Branko Cibej]
>> Like I said in my response to this in the other thread -- API or even
>> ABI compatibility is not the issue. Working copy formats, wire
>> protocol quirks, etc. etc. are more "interesting". And I really don't
>> think it's up to us to
On 08.07.2012 17:47, Mattias Engdegård wrote:
> 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
On 16.07.2012 14:11, Bert Huijben wrote:
> Hi,
>
> On the Berlin hackathon the suggestion was raised that it might help that we
> standardize a new 'svn:branch' property to give tooling a hint on what
> directories are branches and which aren't. To make sure we don't forget
> about this idea
On 16.07.2012 19:51, Bert Huijben wrote:
> I'm not saying directories aren't branches. I'm just suggesting that
> we give tools a hint to what directories are used as branches.
I said that directories /aren't/ branches. :)
> And I'm not alone in this wish. Subclipse and at least one other client
On 17.07.2012 03:59, Greg Stein wrote:
> On Jul 16, 2012 1:18 PM, "Branko Čibej" wrote:
>> ...
>> Please describe the set of use cases you want to address, propose how
>> you think this new property can solve them, and at the very least,
>> explain how the
On 17.07.2012 07:14, Trent Nelson wrote:
[a description of Enversion]
Thanks, Trent -- this was a very good description.
So what we have here is a tool that provides additional branch semantics
on top of Subversion's data model and controls commits to protect the
repository against several kinds
On 17.07.2012 21:08, Julian Foad wrote:
> I know it would be nice and convenient if it was defined centrally
> here, but ... I dunno, others may disagree, but I think we need a much
> more rigorous definition before I'd be happy to consider it.
Thank you, Julian, for putting it so clearly.
--
Ce
On 17.07.2012 22:55, Julian Foad wrote:
> Branko Čibej wrote:
>> On 17.07.2012 21:08, Julian Foad wrote:
>>> I know it would be nice and convenient if it was defined centrally
>>> here, but ... I dunno, others may disagree, but I think we need a much
>>>
On 18.07.2012 09:47, Bert Huijben wrote:
>
>> -Original Message-
>> From: br...@apache.org [mailto:br...@apache.org]
>> Sent: woensdag 18 juli 2012 03:46
>> To: comm...@subversion.apache.org
>> Subject: svn commit: r1362739 -
>> /subversion/trunk/subversion/tests/cmdline/basic_tests.py
>>
>
On 18.07.2012 10:51, Philip Martin wrote:
> "Bert Huijben" writes:
>
>> In 1.6 all these cases worked because we found a .svn directory with
>> metadata in the immediate parent (=the symlinked directory).
>>
>> I'm not sure if we really want to support all these corner cases
>> (including those wh
On 18.07.2012 12:25, Bert Huijben wrote:
>
>> -Original Message-
>> From: Branko Čibej [mailto:br...@wandisco.com]
>> Sent: woensdag 18 juli 2012 11:50
>> To: dev@subversion.apache.org
>> Subject: Re: svn commit: r1362739 -
>> /subversion/trunk/
On 23.07.2012 21:33, Trent Nelson wrote:
>> CPU 7 1 instruction cache TSC 991bb5281cc5
>> ADDR 7c3cffe80
>> Instruction cache ECC error
>>bit46 = corrected ecc error
>>bit62 = error overflow (multiple errors)
Oops.
>> (P.S. Anyone in the market for a cheap Sun Fire v40z? Very
On 02.08.2012 22:18, Greg Stein wrote:
> I like the general idea here, but would suggest details like this could
> fall under --version --verbose. Apache httpd has a similar feature which
> also prints other #define values. For example, maybe we could print version
> info for the libs we compiled a
101 - 200 of 2896 matches
Mail list logo
