3 maj 2013 kl. 00.49 skrev janI:
I looked at the patch, and found a single item which I think should
be changed.
Many thanks!
you translate "bogus" with "felaktig", in my opion that is too
strong..."bogus" does not really mean "Error" but something like
"we do not understand what you w
On 3 May 2013 09:58, Mattias Engdegård wrote:
> 3 maj 2013 kl. 00.49 skrev janI:
>
>
> I looked at the patch, and found a single item which I think should be
>> changed.
>>
>
> Many thanks!
No problem, danielsh asked me to look at it, which I happely did. He is the
one that can apply the patch
On Fri, May 03, 2013 at 10:19:53AM +0200, janI wrote:
> On 3 May 2013 09:58, Mattias Engdeg?rd wrote:
>
> > 3 maj 2013 kl. 00.49 skrev janI:
> >
> >
> > I looked at the patch, and found a single item which I think should be
> >> changed.
> >>
> >
> > Many thanks!
>
>
> No problem, danielsh ask
On Fri, May 03, 2013 at 09:58:21AM +0200, Mattias Engdegård wrote:
> Again, thanks for looking at my translation. This effort has made me
> realise how much time a translator spends in attempting to figure out
> what the programmer actually meant, and by consequence how important
> clarity is
On 05/02/2013 04:45 PM, Mattias Engdegård wrote:
> It is quite annoying that some of the more common error messages, the
>
> svn: invalid option: --gurgle
>
> kind, are entirely untranslatable because they are printed directly by
> APR which does not have any concept of translation at all. (This
C. Michael Pilato wrote on Fri, May 03, 2013 at 08:56:25 -0400:
> On 05/02/2013 04:45 PM, Mattias Engdegård wrote:
> > It is quite annoying that some of the more common error messages, the
> >
> > svn: invalid option: --gurgle
> >
> > kind, are entirely untranslatable because they are printed dir
cmpil...@tigris.org wrote on Fri, May 03, 2013 at 07:48:07 -0700:
> It is not unreasonable to think that my runtime configuration area could have
> been created by a Subversion 1.7 client, but that from time to time I need to
> use a 1.6 client on the same machine. Users in such situations might b
Ben Reser writes:
> There are some changes in STATUS that we should finish voting for. Of
> particular note is Branko's case-sensitivity change.
It doesn't seem to be attracting votes so postpone the change to 1.9 and
roll a tarball without it.
--
Certified & Supported Apache Subversion Downl
On 05/03/2013 02:09 PM, Philip Martin wrote:
> Ben Reser writes:
>
>> There are some changes in STATUS that we should finish voting for. Of
>> particular note is Branko's case-sensitivity change.
>
> It doesn't seem to be attracting votes so postpone the change to 1.9 and
> roll a tarball witho
On Mon, Apr 29, 2013 at 3:42 PM, Ben Reser wrote:
> Unless someone is aware of something else, once we wrap up some of the
> STATUS changes I think we can cut a release candidate for 1.8.0,
> probably this week?
The something else is the CHANGES file. I took a look at our CHANGES
and it's defini
On Fri, May 3, 2013 at 11:43 AM, Ben Reser wrote:
> The something else is the CHANGES file. I took a look at our CHANGES
> and it's definitely not complete. :(
Can someone else help with taking on some of these:
http://wiki.apache.org/subversion/Svn18Changes
On Fri, May 3, 2013 at 11:19 AM, C. Michael Pilato wrote:
> I'm trying to review stuff as we speak. I'll focus on Brane's change now,
> since it is an API change.
I was going to review it myself but since you are I'll just let you do it.
On 05/03/2013 02:43 PM, Ben Reser wrote:
> On Mon, Apr 29, 2013 at 3:42 PM, Ben Reser wrote:
>> Unless someone is aware of something else, once we wrap up some of the
>> STATUS changes I think we can cut a release candidate for 1.8.0,
>> probably this week?
>
> The something else is the CHANGES f
Paul,
Was reviewing your svn_client_log5() changes. There are a couple of places
in your reworked svn_client_log5() code (resolve_log_targets(),
specifically) that read like so or similar:
if (peg_revision->kind == svn_opt_revision_unspecified)
(*peg_revision).kind = svn_opt_re
On Fri, May 3, 2013 at 12:03 PM, C. Michael Pilato wrote:
> We can roll RC1 without CHANGES being up to date and then do that work
> during the four-week soak period.
You're right, for some reason I was thinking we just renamed the
tarballs, but the SVN_VER_TAG and SVN_VER_NUMTAG have to be chang
On Wed, May 1, 2013 at 8:07 AM, Gabriela Gibson
wrote:
> Should this note be a comment in get-deps.sh?
Done in r1478951.
Hi Paul.
A bit more review.
> + If TARGETS contains a single URL and one or more relative paths, then
> + set *RA_TARGET to a copy of that URL and *CONDENSED_PATHS to a copy of
> + each relative path after the URL.
> [...]
> +resolve_log_targets()
s/CONDENSED_PATHS/RELATIVE_TARGETS/.
> +f
I (Julian Foad) wrote:
> These functions:
>
> resolve_wc_opt_revs()
> resolve_wc_head_revs()
> resolve_wc_date_revs()
>
> together with the code that calls them, seem to be implementing the basic
> "convert an svn_opt_revision_t to a revision number" functionality
> that we already have
I (Julian Foad) wrote:
> I (Julian Foad) wrote:
>> These functions:
>>
>> resolve_wc_opt_revs()
>> resolve_wc_head_revs()
>> resolve_wc_date_revs()
>>
>> together with the code that calls them, seem to be implementing the basic
>> "convert an svn_opt_revision_t to a revision number" fu
I (Julian Foad) wrote:
> I (Julian Foad) wrote:
>>> [...] can't we simply open [a session] before calling this
>>> function, and let this function make simple calls to
>>> svn_client__get_revision_number()?
>>
>> The attached patch implements this,
[...]
> Committed revision 1478998.
I don't
> Author: pburba
> Date: Fri May 3 21:50:52 2013
> New Revision: 1478987
>
> URL: http://svn.apache.org/r1478987
> Log:
> A small bit of issue #4351 'improve automatic merge performance' work:
> Avoid
> one to two network roundtrips to get the *same* mergeinfo catalogs while
> calculating autom
Here it is: the first Release Candidate for Subversion 1.8.0. You can
fetch the proposed tarballs from here:
https://dist.apache.org/repos/dist/dev/subversion
The magic rev is r1478983
This is a release candidate, meaning if all goes well it (or something
very much like it) will become the fin
Ben Reser wrote on Fri, May 03, 2013 at 13:00:10 -0700:
> On Wed, May 1, 2013 at 8:07 AM, Gabriela Gibson
> wrote:
> > Should this note be a comment in get-deps.sh?
>
> Done in r1478951.
The same warning applies equally well to configure.ac and really to any
sh code we write for users to run. I
Ben Reser wrote on Fri, May 03, 2013 at 17:34:49 -0700:
> Reminder that the STATUS file is still for 1.8.0, please be careful
> about moving changes to the approved section and only move changes
> that appropriate to be merged at this point (i.e. changes that would not
> restart our soak).
That's
On Fri, May 3, 2013 at 10:12 PM, Daniel Shahaf wrote:
> That's a little confusing workflow: "To approve a backport, move it to
> the end of the file, unless the RM said the file on dev@ is frozen".
Well the branch isn't really frozen. It's just restricted to things
that don't restart our soak.
On Fri, May 3, 2013 at 10:05 PM, Daniel Shahaf wrote:
> The same warning applies equally well to configure.ac and really to any
> sh code we write for users to run. I could see it lifted into the
> coding style guidelines part of HACKING, for example.
Noted and adding to my todo list.
26 matches
Mail list logo
