CMP> Finished.
CMP>Sendingsubversion/mod_dav_svn/dav_svn.h
CMP>Sendingsubversion/mod_dav_svn/repos.c
CMP>Transmitting file data ..
CMP>Committed revision 1466055.
Great! Thanks a lot, Michael!
--
Best regards,
jinfrostermailto:jinfr
Figured it out.
We do not currently expose the noIgnore variable in Subclipse code. I
recently "fixed" the code to at least have an internal noIgnore
variable that I hard coded to false. Previously I was passing in a
different variable that happened to be true. So this is what changed
the behav
We are looking into a Subclipse problem. It seems that with 1.7.9
when we call the SVN status API with the equivalent of the -v option
we are no longer getting back ignored resources in the list. Is that
a behavior change that anyone recalls?
We did make a JavaHL fix in this release, but I think
> -Original Message-
> From: cmpil...@apache.org [mailto:cmpil...@apache.org]
> Sent: dinsdag 9 april 2013 21:15
> To: comm...@subversion.apache.org
> Subject: svn commit: r1466183 - in /subversion/trunk/subversion:
> include/svn_auth.h include/svn_config.h libsvn_subr/auth.c
> libsvn_sub
On Fri, Apr 5, 2013 at 7:47 PM, Daniel Shahaf wrote:
> THanks for the review, commnts inline:
>
Sorry for late reply. See my reply inline.
> Ivan Zhakov wrote on Fri, Apr 05, 2013 at 19:40:16 +0400:
>> On Fri, Apr 5, 2013 at 6:47 PM, wrote:
>> > + /** Filesystem backend (#fs_type) -specific in
On 09.04.2013 21:57, Julian Foad wrote:
>> Branko Čibej wrote:
URL: http://svn.apache.org/r1465454
Log:
* site/publish/docs/release-notes/1.8.html: Add a section about BDB
deprecation.
>>> Please review:
>>> http://subversion.apache.org/docs/release-notes/1.8.html#bdb-deprecate
> Branko Čibej wrote:
>>> URL: http://svn.apache.org/r1465454
>>> Log:
>>> * site/publish/docs/release-notes/1.8.html: Add a section about BDB
>>> deprecation.
>>
>> Please review:
>> http://subversion.apache.org/docs/release-notes/1.8.html#bdb-deprecated
The opening paragraph sounds rather apol
C. Michael Pilato wrote:
> On 04/09/2013 11:45 AM, Branko Čibej wrote:
>> I frankly cannot recall a single tool that localizes its command line,
>> either commands, options or option values. That way lies insanity; you
>> might as well localize C.
>
> Agreed. Madness.
>
>> On the other hand
On 04/09/2013 11:45 AM, Branko Čibej wrote:
> I frankly cannot recall a single tool that localizes its command line,
> either commands, options or option values. That way lies insanity; you
> might as well localize C.
Agreed. Madness.
> On the other hand, I wouldn't mind localizing the interacti
Stefan Sperling wrote:
> On Tue, Apr 09, 2013 at 03:08:33PM +0100, Julian Foad wrote:
>> I assume you mean the command line is not translated as a matter of
>> policy? Technically I see no reason why it cannot be translated. If
>> the reason why we don't is so that scripts can be locale-independe
On 09.04.2013 16:27, Stefan Sperling wrote:
> On Tue, Apr 09, 2013 at 03:08:33PM +0100, Julian Foad wrote:
>> I assume you mean the command line is not translated as a matter of
>> policy? Technically I see no reason why it cannot be translated. If
>> the reason why we don't is so that scripts ca
2013/4/8 Ben Reser :
> On Mon, Apr 8, 2013 at 10:26 AM, Konstantin Kolinko
> wrote:
>> Regarding 1.6.x, all versions (except a few 1.7 betas) between April
>> 2010 and February 2012 were announced on that list. This includes
>> 1.6.11 .. 1.6.17 and 1.5.9. Announcements ceased since March 2012 for
On 04/09/2013 09:46 AM, C. Michael Pilato wrote:
> On 04/07/2013 01:38 PM, jinfroster wrote:
>> + keyword_subst = apr_table_get(pairs, "kw");
>> + if (keyword_subst && *keyword_subst != '0')
>> +comb->priv.keyword_subst = TRUE;
>> +
>>return NULL;
>> }
>
> I'm with Daniel -- this should
On Tue, Apr 09, 2013 at 03:08:33PM +0100, Julian Foad wrote:
> I assume you mean the command line is not translated as a matter of
> policy? Technically I see no reason why it cannot be translated. If
> the reason why we don't is so that scripts can be locale-independent,
> then it would still be
Stefan Sperling wrote:
> On Mon, Apr 08, 2013 at 10:15:33AM +0100, Philip Martin wrote:
>> Mattias Engdegård writes:
>>
>> > The conflict prompt is no longer localised, probably because of an
>> > oversight.
[...]
>> Do we want the long options localised? If I run
>>
>> svn update --ac
On 04/07/2013 01:38 PM, jinfroster wrote:
> Index: subversion/mod_dav_svn/dav_svn.h
> ===
> --- subversion/mod_dav_svn/dav_svn.h (revision 1465320)
> +++ subversion/mod_dav_svn/dav_svn.h (working copy)
> @@ -289,6 +289,9 @@
>
>
On Wed, Apr 03, 2013 at 01:04:43PM +0200, Stefan Sperling wrote:
> To refresh our collective memory, the current trunk code does:
> - prevent newlines from entering filenames at the fsfs layer
> - prevent control characters from entering filenames at the repos layer
I have nominated backports of
On 09.04.2013 11:35, Bert Huijben wrote:
> Svnsync should support mirroring a subtree. Only the initial version
> couldn’t do that.
So I understand, especially trunk svnsync; but "svnsync init" kept
complaining that the source URL was not a repository root, so I gave up
for now. I'll investigate a
Curious if 'svnrdump1.7 dump | svnrdump1.8 load' would double-free too.
(or is that one of the thinsg we fixed in trunk)
Branko Čibej wrote on Tue, Apr 09, 2013 at 05:38:45 +0200:
> With 1.7.x tools, about 2/3 of the way through, svnadmin complained
> about seeing an unknown field in the dump stre
Svnsync should support mirroring a subtree. Only the initial version couldn’t
do that.
Bert
Sent from Windows Mail
From: Branko Čibej
Sent: Tuesday, April 9, 2013 5:38 AM
To: Subversion Development
This is not a complaint, just an observation. :)
I spent the last couple days
20 matches
Mail list logo
