Stefan Sperling wrote on Sat, Apr 13, 2013 at 01:55:01 +0200:
> On Fri, Apr 12, 2013 at 02:34:26PM -0400, C. Michael Pilato wrote:
> > svn: E180003: Unable to connect to a repository at URL
> > 'file:///home/cmpilato/tests/arch'
> > svn: E180012: Unable to open an ra_local session to URL
> > svn: E
On Fri, Apr 12, 2013 at 02:34:26PM -0400, C. Michael Pilato wrote:
> svn: E180003: Unable to connect to a repository at URL
> 'file:///home/cmpilato/tests/arch'
> svn: E180012: Unable to open an ra_local session to URL
> svn: E180001: Unable to open repository 'file:///home/cmpilato/tests/arch'
> (
Please use text/* MIME type for attachments.
Mattias Engdegård wrote on Fri, Apr 12, 2013 at 22:04:57 +0200:
> + result = apr_pstrcat(pool, result,
> + _("Words in square brackets are the corresponding "
> + "--accept option arguments.\n"),
> +
Yay, a bikeshed discussion!
[Daniel Shahaf]
> % $svn upgrade /
> subversion/svn/upgrade-cmd.c:73: (apr_err=_)
> subversion/libsvn_client/upgrade.c:112: (apr_err=_)
> subversion/libsvn_wc/upgrade.c:2194: (apr_err=_)
> subversion/libsvn_wc/wc_db.c:15006: (apr_err=SVN_ERR_WC_INVA
On Sat, Apr 13, 2013 at 12:14 AM, Branko Čibej wrote:
> On 12.04.2013 22:06, Ben Reser wrote:
>> On Fri, Apr 12, 2013 at 11:53 AM, Daniel Shahaf wrote:
>>> Another idea: avoid printing the (apr_err=) part if it's the same code as
>>> the
>>> line above it (which should be the common case):
>>>
>
On Fri, Apr 12, 2013 at 8:27 PM, Daniel Shahaf wrote:
> Prompted by Julian's review of this freshly-minted public API on IRC:
>
> 1. Question to API consumers (eg, client developers): would you find
> this API useful? For reference, the current docstring is attached.
>
I think it *may be* useful
On 12.04.2013 22:06, Ben Reser wrote:
> On Fri, Apr 12, 2013 at 11:53 AM, Daniel Shahaf wrote:
>> Another idea: avoid printing the (apr_err=) part if it's the same code as the
>> line above it (which should be the common case):
>>
>> subversion/svn/checkout-cmd.c:168
>> (apr_err=SVN_ERR_RA_LOCAL_
On Fri, Apr 12, 2013 at 11:53 AM, Daniel Shahaf wrote:
> Another idea: avoid printing the (apr_err=) part if it's the same code as the
> line above it (which should be the common case):
>
> subversion/svn/checkout-cmd.c:168 (apr_err=SVN_ERR_RA_LOCAL_REPOS_OPEN_FAILED)
> subversion/libsvn_client/ch
12 apr 2013 kl. 20.33 skrev Mattias Engdegård:
To make progress, I'll prepare another patch that avoids this
particular point of disagreement.
And here it is. Now the (unlocalised) --accept options are explicitly
shown in the long help, but not the prompt labels, since they are
redundant,
Daniel Shahaf wrote on Fri, Apr 12, 2013 at 22:55:59 +0300:
> (And, FTR, the condition in my previous patch should have been just
> "svn_error__is_tracing_link().)
Committed that in r1467440 since it does make the code less cluttered;
we can tweak it further as this thread converges upon other opt
C. Michael Pilato wrote on Fri, Apr 12, 2013 at 15:49:43 -0400:
> On 04/12/2013 03:42 PM, Daniel Shahaf wrote:
> > Actually I got my stack reversed. It's easier to implement a "See
> > below" than a "See above", and of course "See below" means the symbolic
> > error is always immediately above the
On 04/12/2013 03:42 PM, Daniel Shahaf wrote:
> Actually I got my stack reversed. It's easier to implement a "See
> below" than a "See above", and of course "See below" means the symbolic
> error is always immediately above the numeric one:
Eh ... not so thrilling.
--
C. Michael Pilato
CollabNe
Daniel Shahaf wrote on Fri, Apr 12, 2013 at 22:22:18 +0300:
> C. Michael Pilato wrote on Fri, Apr 12, 2013 at 15:16:23 -0400:
> > On 04/12/2013 02:53 PM, Daniel Shahaf wrote:
> > > Another idea: avoid printing the (apr_err=) part if it's the same code as
> > > the
> > > line above it (which should
C. Michael Pilato wrote:
> On 04/12/2013 01:36 PM, Julian Foad wrote:
>> I'll branch at about 18:30 UTC (less than an hour from now) if all
>> still looks well at that time.
>
> Sounds good.
r1467414: Branch created.
r1467415: Trunk version number bumped.
r1467428: STATUS file added on branch
C. Michael Pilato wrote on Fri, Apr 12, 2013 at 15:16:23 -0400:
> On 04/12/2013 02:53 PM, Daniel Shahaf wrote:
> > Another idea: avoid printing the (apr_err=) part if it's the same code as
> > the
> > line above it (which should be the common case):
> >
> > subversion/svn/checkout-cmd.c:168
> >
On 04/12/2013 02:53 PM, Daniel Shahaf wrote:
> Another idea: avoid printing the (apr_err=) part if it's the same code as the
> line above it (which should be the common case):
>
> subversion/svn/checkout-cmd.c:168 (apr_err=SVN_ERR_RA_LOCAL_REPOS_OPEN_FAILED)
> subversion/libsvn_client/checkout.c:1
Mattias Engdegård wrote on Fri, Apr 12, 2013 at 20:33:34 +0200:
> 12 apr 2013 kl. 19.52 skrev Daniel Shahaf:
>
>> On Fri, Apr 12, 2013 at 07:44:23PM +0200, Mattias Engdeg?rd wrote:
>>> This is about a user being asked a question in her native language
>>> and
>>> given a set of answers labelled i
On Fri, Apr 12, 2013 at 02:34:26PM -0400, C. Michael Pilato wrote:
> Daniel, I find the current error display really ... weighty, for lack of a
> better term. It's difficult to pick out the meat of the message amongst the
> overwhelming amount of repetitive, all-caps symbolic names of error codes.
On 04/12/2013 02:15 PM, Philip Martin wrote:
> "C. Michael Pilato" writes:
>
>> We know the branch isn't RC-ready, so if we cut a tarball, it would be
>> "beta1".
>
> What needs to happen to make it RC-ready?
*
http://subversion.tigris.org/issues/buglist.cgi?target_milestone=1.8.0&issue_status=
Daniel, I find the current error display really ... weighty, for lack of a
better term. It's difficult to pick out the meat of the message amongst the
overwhelming amount of repetitive, all-caps symbolic names of error codes.
Something to consider: omit the symbolic name from the printed error l
12 apr 2013 kl. 19.52 skrev Daniel Shahaf:
On Fri, Apr 12, 2013 at 07:44:23PM +0200, Mattias Engdeg?rd wrote:
This is about a user being asked a question in her native language
and
given a set of answers labelled in that language. Why force her to
reply in a code dissonant to those answers?
Philip Martin writes:
> "C. Michael Pilato" writes:
>
>> We know the branch isn't RC-ready, so if we cut a tarball, it would be
>> "beta1".
>
> What needs to happen to make it RC-ready?
CHANGES needs to be completed. Anything else?
--
Philip
"C. Michael Pilato" writes:
> We know the branch isn't RC-ready, so if we cut a tarball, it would be
> "beta1".
What needs to happen to make it RC-ready?
--
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
On 04/12/2013 01:36 PM, Julian Foad wrote:
> I'll branch at about 18:30 UTC (less than an hour from now) if all still
> looks well at that time.
Sounds good.
> The releasing guidelines say to create the CHANGES section for 1.8 on
> trunk after branching, but that was done long ago. In fact, we p
Daniel Shahaf wrote:
> Prompted by Julian's review of this freshly-minted public API on IRC:
>
> 1. Question to API consumers (eg, client developers): would you find
> this API useful? For reference, the current docstring is attached.
>
> 2. Should we print the symbolic name in release builds?
On Fri, Apr 12, 2013 at 07:44:23PM +0200, Mattias Engdeg?rd wrote:
> This is about a user being asked a question in her native language and
> given a set of answers labelled in that language. Why force her to
> reply in a code dissonant to those answers?
Because the user should be able to answ
On Fri, Apr 12, 2013 at 1:39 PM, Julian Foad wrote:
> Paul Burba wrote:
>
>> On Thu, Apr 11, 2013 at 5:15 PM, wrote:
>>> http://subversion.tigris.org/issues/show_bug.cgi?id=2897
>>>
>>> User julianfoad changed the following:
>>>
>>> What|Old value |New valu
12 apr 2013 kl. 12.21 skrev Branko Čibej:
On 11.04.2013 20:47, Mattias Engdegård wrote:
And if you would agree to that, why should we deny others the same
benefits?
For the same reason that I'd deny them the dubious benefit of, e.g.,
the
following:
nepredznačeno celo_število Fibonacci
On 04/11/2013 02:47 PM, Mattias Engdegård wrote:
> 11 apr 2013 kl. 14.24 skrev C. Michael Pilato:
>
> Do you really claim that any set of single- and two-letter codes is as good
> as another?
No, I cannot make, and am not making, that claim. I do claim the following:
* The long-form conflict a
Paul Burba wrote:
> On Thu, Apr 11, 2013 at 5:15 PM, wrote:
>> http://subversion.tigris.org/issues/show_bug.cgi?id=2897
>>
>> User julianfoad changed the following:
>>
>> What |Old value |New value
>> ===
Stefan Fuhrmann wrote:
> C. Michael Pilato wrote:
>> Julian Foad wrote:
>>> So shall we get this branch branched very soon? For the sake of making a
>>> decision, I'll suggest that we should try hard to get the things above
>>> resolved by the end of tomorrow, and that even if we don't they are no
On 04/12/2013 12:27 PM, Daniel Shahaf wrote:
> Prompted by Julian's review of this freshly-minted public API on IRC:
>
> 1. Question to API consumers (eg, client developers): would you find
> this API useful? For reference, the current docstring is attached.
N/A
> 2. Should we print the symboli
Prompted by Julian's review of this freshly-minted public API on IRC:
1. Question to API consumers (eg, client developers): would you find
this API useful? For reference, the current docstring is attached.
2. Should we print the symbolic name in release builds? For example:
% $svn upgrade
Hi Julian.
On 11.04.2013 05:10, Julian Foad wrote:
> Hi Matthias. Thanks for your email, and sorry it was so long before I looked
> back in my mailbox and replied.
>
> Matthias Buecher wrote on 2013-02-02:
>
>> the contrib script "detect-merge-conflicts.sh" [1] uses a grep command
>> which al
I was optimising for readability, not portability.
On Fri, Apr 12, 2013 at 07:46:14AM -0700, Ben Reser wrote:
> I tend to think the absolute URL syntax is better for our
> documentation since the only way the relative URL works is if you run
> it while your CWD is in a working copy in that repo.
>
One absolute URL is enough, the other can be relative.
Ben Reser writes:
> I tend to think the absolute URL syntax is better for our
> documentation since the only way the relative URL works is if you run
> it while your CWD is in a working copy in that repo.
>
> On Fri, Apr 12, 2013 at 6:32 AM,
I tend to think the absolute URL syntax is better for our
documentation since the only way the relative URL works is if you run
it while your CWD is in a working copy in that repo.
On Fri, Apr 12, 2013 at 6:32 AM, wrote:
> Author: danielsh
> Date: Fri Apr 12 13:32:31 2013
> New Revision: 1467266
That has been a fresh checkout with /trunk from about 1 week ago
and the command line has been copied verbatim into my post.
The only special circumstance here is that the external repositories
were not available during checkout. Maybe those errors interfered
with table contents being written?
--
On Thu, Apr 11, 2013 at 5:15 PM, wrote:
> http://subversion.tigris.org/issues/show_bug.cgi?id=2897
>
>
>
> User julianfoad changed the following:
>
> What|Old value |New value
>
>
There is as far as I can tell no code in Subversion that can generate ../ style
paths from an abspath for you. Are you sure this is how you invoked ‘svn’ or
did you invoke ‘svn'via a similar ../ path (maybe via a script)? It should show
paths in exactly the same way as you provided them to svn.
On 04/11/2013 05:39 PM, Gabriela Gibson wrote:
> This patch plugs in a new option --invoke-diff-cmd into the existing
> diff command structure, but does leave the existing "diff-cmd" option
> untouched.
>
> This addition allows the user to define a complex diff command, to be
> applied in place of
Hi,
While playing around with large working copies, I discovered
that we display externals as rather odd relative paths:
/home/stefan/develop/trunk$ ./subversion/svn/svn st /mnt/hdds/apache
X ../../../../mnt/hdds/apache/lucene/pylucene/tags/pylucene_3_0_2/jcc
X ../../../../mnt/hdds/ap
On 11.04.2013 20:47, Mattias Engdegård wrote:
> Do you really claim that any set of single- and two-letter codes is as
> good as another? I don't think so -- I believe "p" to be better
> answer for "postpone" than "4" or "mc" in English, one that will both
> reach the state of memorisation much qu
43 matches
Mail list logo
