RC3 next week and restart
the soak period?
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
On 17.05.2013 15:58, Ivan Zhakov wrote:
> On Fri, May 17, 2013 at 5:53 PM, Branko Čibej wrote:
>> On 17.05.2013 15:32, i...@apache.org wrote:
>>> --- subversion/branches/1.8.x/STATUS (original)
>>> +++ subversion/branches/1.8.x/STATUS Fri May 17 13:32:56 2013
>>
make FSFS /much/ faster if
we didn't worry about atomically installing revision files. But
performance has always been secondary to robustness, in both the server
side /and/ the working copy.
Instead of screaming at people about performance loss, a more
constructive approach would be to propose an alternative solution that
fixes the same bug differently, but just as completely.
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
As far as I
know, we don't have any performance data that could help us decide.
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
EGORY_CONFIG);
>> + svn_config_t *cfg;
>> +
>> + cfg = svn_hash_gets(config, SVN_CONFIG_CATEGORY_CONFIG);
> Why? This doesn't seem to serve any useful purpose (in fact, I think it makes
> the code harder to read).
Indeed, we tend to prefer the original form.
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
NULL,
> +ctx, pool));
>SVN_ERR(svn_stream_puts(outstream, _("\n")));
>return SVN_NO_ERROR;
> }
The last hunk contains tabs. There should be no tabs in our source
files, ever.
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
o generate events for revprop and other unversioned metadata changes
o proper Pythonic packaging
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
t
/global/ variable declarations (and in that case, I agree). These are
local variables and behave quite differently.
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
.org/wiki/Diff
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
while ((p + len + 4) <= end)
If the above condition is correct ...
[...]
>> + else
>> +{
>> + /* use our optimized sub-routine to find the next EOL */
>> + const char *eol
>> += svn_eol__find_eol_start((char *)p + len, end - p);
... then the second parameter here should be (end - p + 1), not (end - p).
>> + len += (eol ? eol : end) - (p + len);
And I don't understand this statement at all.
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
ake serf 1.2.0 work:
I suggest you report this to the Serf project
(https://code.google.com/p/serf/)
I don't actually bother with Serf all on Mac OS; I just use the one from
homebrew.
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
commit handler to accept and ignore it.
It would probably be a good idea to backport this to 1.8.x, ecause
currently the svnpubsub's commit-hook.py does not work with a 1.8 server.
Opinions?
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
valid args\n")
>> +sys.exit(0)
>> +
> Same.
I was wondering about that myself. I basically just copied the behaviour
of the commit-hook.
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
, extract wrapper for subprocess.check_output into a common
>> utility
>> module. And make problems in the server hooks more visible by exiting with an
>> error if the hook fails to run.
>>
> Should the exit code fix be backported?
IMO, we can backport the whole set
ed.sch"/> value="eagleTests2/untitled.sch"/> value="162"/>
>
> please note that the expansion is cut-off in the middle of
> ' fixed and to small buffer size.
That is not a bug. See
http://subversion.apache.org/docs/release-notes/1.8.html#custom-keywords
w
On 27.05.2013 10:22, Branko Čibej wrote:
> On 27.05.2013 06:41, Daniel Shahaf wrote:
>> On Sun, May 26, 2013 at 09:22:48PM +, Daniel Shahaf wrote:
>>> On Sun, May 26, 2013 at 08:06:47PM -, br...@apache.org wrote:
>>>> +def main(repo, revision, author, pro
notes/meetings/berlin-13-agenda
I'd have expected this to be in the wiki ... do you mind if I move it there?
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
On 29.05.2013 01:31, Stefan Fuhrmann wrote:
>
> On Wed, May 29, 2013 at 1:27 AM, Branko Čibej <mailto:br...@wandisco.com>> wrote:
>
> On 29.05.2013 01:20, Stefan Fuhrmann wrote:
> > Hi all,
> >
> > We had a list of items for discussion in 201
use as the basis for all
our script bindings.
But I'd never recommend rewriting parts of our code in C++; that'd make
our 18-month release cycle for 1.8 look like a half-day holiday in
comparison.
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
way from "Hello, world!" to
something closer to the complexity of real projects.
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
.
>
> Also our company provides binary distribution of Subversion and this
> job also need my attention. That means less hacking and face to face
> discussions at least for me :(
Agreed -- let's have the release party in Berlin and /then/ make the
release. :)
-- Brane
--
Branko Č
27;t be surprised if that was the case on Windows, however, APR
does not map its error codes from errno but from Win32 status codes. So
I suspect this is a red herring and a side effect of the symbolic error
code printout thing. Very likely, the mapping generator is just a wee
bit too Unix-centric.
My sincerest apologies for that crud at the end of my previous mail in
this thread. Someone decided just a couple hours ago that it's a good
idea to unconditionally add that mess to outgoing messages from a
particular domain, and so I'm no longer sending messages to this list
from that domain until
On 31.05.2013 06:57, Daniel Shahaf wrote:
> Branko Čibej wrote on Thu, May 30, 2013 at 22:40:11 +0200:
>> On 30.05.2013 21:59, Johan Corveleyn wrote:
>>> Running gen-make.py on trunk@1487954, I get the following warning at the
>>> end:
>>>
>>> [[[
On 31.05.2013 14:52, Julian Foad wrote:
> Bert Huijben wrote:
>
>>> Author: julianfoad
>>> URL: http://svn.apache.org/r1487954
>>> Log:
>>> * build/generator/gen_base.py
>>>(TargetLinked): Remove some redundant and wrong code.
>>>(_collect_paths): Document what happens if the pattern is
On 31.05.2013 17:27, C. Michael Pilato wrote:
> On 05/31/2013 11:23 AM, C. Michael Pilato wrote:
>> On 05/31/2013 10:35 AM, Julian Foad wrote:
>>> Just an opinion from general experience in the world of computers. With
>>> any system where some resource is reserved (locked), it can be useful to
>>
On 02.06.2013 04:07, Ben Reser wrote:
> I was hoping someone else would weigh in here. But I guess not.
>
> On Tue, May 28, 2013 at 11:15 AM, Greg Stein wrote:
>> You guys are over-thinking it. Simply state this format is ASF-wide
>> and be done with it.
> Okay but should we ask anyone before we
On 03.06.2013 11:30, Bert Huijben wrote:
> This function is also used from deprecated code in libsvn_cliënt and
> some binding code, unlike most other deprecated code...
>
> In some ways this code is 'a bit less deprecated' ;-)
And anyway, only public APIs can be deprecated. Private APIs are eithe
On 03.06.2013 12:47, Neels Hofmeyr wrote:
> Hi dev,
>
> I tried to get svnperms.py going on a windows server (),
> but needed this patch to do so:
>
> http://svn.haxx.se/dev/archive-2009-04/0668.shtml
>
> It seems that no-one has answered Sergey on his patch submission back
> in 2009. (According to
I think it's clear that we have to wait for a Serf bugfix release before
releasing RC3, and during that time our soak period is simply on hold.
What happens after Serf 1.2.1 is released depends on the changes there.
If it's just a trivial bugfix for the digest authn issue, then we can
simply contin
dd the proper defines
to your serf Visual Studio project. It would appear that gen-make.py
didn't find your Serf library where you told it to look, but it should
warn you about that.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. br...@wandisco.com
On 07.06.2013 15:41, Ben Brown wrote:
> On Fri, Jun 7, 2013 at 3:33 PM, Branko Čibej <mailto:br...@wandisco.com>> wrote:
>
> It would appear that gen-make.py didn't find your Serf library
>
> where you told it to look, but it should warn you about that.
>
&
On 07.06.2013 15:54, Ben Brown wrote:
> On Fri, Jun 7, 2013 at 3:44 PM, Branko Čibej <mailto:br...@wandisco.com>> wrote:
>
> Not likely. Can you please look at any of your generated
> .vc(x)proj files in build/win32 and see if it contains compiler
> options to
UniP/6R5mdvqJ4XaYIJn9hhdg2S8+VBoeIPuYkATuloR+xz96mkU7wQlI0fF
RAhqHjK1sl09IIEtgc8QnVomkGZpD97MhX1j/GWyJpBVH7HnM5xc3mz/XLmPsHY=
=Kvnf
-END PGP SIGNATURE-
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. br...@wandisco.com
project generator; I propose to remove it
completely instead. It's time, IMO.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. br...@wandisco.com
On 11.06.2013 10:45, Julian Foad wrote:
> If there's a scheme that we're already using in Subversion, that would
> be a good choice. Is there one?
Yes; the one we already use in config files, which is a ripoff from Python.
In this case you'd have to use %%(foo)s in the config file instead of
%(fo
nadmin create" new flags to control
these features? Editing fsfs.conf every time one creates a new
repository would tend to become a bit tedious.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. br...@wandisco.com
discard edit (breaks
> move),
>>>> Why does discarding the incoming edit break the (local) move?
>> I was wondering the same thing.
>>
>>> The copy/add part would be of a different revision than the delete part
> of
>>> the move if you don't apply the move.
>> That doesn't make any sense to me as a user. "Discard edit" sounds like
> it
>> means "act as if the incoming edit was a no-op"... and I would not expect
> a
>> no-op to break the local move.
> The options the interactive conflict editor displays don't reflect the
> actual state if you look at it in this way.
>
> At the time we are resolving the BASE nodes at the original location have
> been updated to the target revision, but the place that the code has been
> moved to is still at the old revision.
I have to wonder why an "svn rename" would affect the BASE tree in any
way? I'd expect /both/ ends of the rename to be recorded in the WORKING
tree, so that an update won't simply overwrite important state information.
In other words -- I suspect this is a design bug.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. br...@wandisco.com
efore I am sharing with the group meanwhile. The following comment
> is from the issue:
>
> https://jira.atlassian.com/browse/FE-4679
>
I would argue that this counts as a bug fix, since property values are
in general not strings.
-- Brane
--
Branko Čibej | Director of Subversion
W
On 12.06.2013 15:42, Bert Huijben wrote:
>
>> -Original Message-
>> From: Branko Čibej [mailto:br...@wandisco.com]
>> Sent: woensdag 12 juni 2013 15:20
>> To: dev@subversion.apache.org
>> Subject: Re: Automatic tree conflicts resolution during svn updat
On 12.06.2013 19:18, Blair Zajac wrote:
> On 06/12/2013 07:07 AM, Branko Čibej wrote:
>> On 12.06.2013 14:42, Vladimir Berezniker wrote:
>>> Hi All,
>>>
>>> I came across a bug in one of the Atlassian tools that suggests that
>>> there was an API compa
me variants symmetrical, or
-rN:M -> [N+1,M]
as you don't really have to find "the next interesting change" -- you
only have to make sure the first bound is inclusive, as with -c, rather
than exclusive, as with -r. That would also imply
-cN:M -> [N+1,M]
and I'm not
r their primary
purpose (i.e., isolating lines of development) seems kind of
counter-productive.
Quite frankly, I'm sometimes just a bit bored by all the conditional
blocks in our code.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. br...@wandisco.com
On 13.06.2013 20:00, Greg Stein wrote:
> On Thu, Jun 13, 2013 at 11:29 AM, Branko Čibej wrote:
>> On 13.06.2013 15:43, Daniel Shahaf wrote:
>>> C. Michael Pilato wrote on Thu, Jun 13, 2013 at 15:27:07 +0200:
>>>> In the interest of serving our user base, we are pro
On 14.06.2013 04:30, Greg Stein wrote:
> On Thu, Jun 13, 2013 at 9:06 PM, Branko Čibej wrote:
>
>> I submit it's time to change that. We've historically done everything on
>> trunk and "released when it's ready," and the result is that every
>&
+1 to release. All the tarballs look OK with the expected differences
from 1.8.0-rc3, and signatures match.
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. br...@wandisco.com
“IF
> FEATURE_IS_ON”. This is standard practice and it's used in Subversion
> now. It doesn’t create code clutter if you remove the switches later.
> * Code review
> * Automated tests
> * Beta testers. People would need to make a commitment. We would run
> the newest versi
z.asc
http://www.apache.org/dist/subversion/subversion-1.8.0.zip.asc
For this release, the following people have provided PGP signatures:
Ben Reser [4096R/16A0DE01] with fingerprint:
19BB CAEF 7B19 B280 A0E2 175E 62D4 8FAD 16A0 DE01
Branko Čibej [2048R/C8628501] with fingerprint:
8769
tember 10, 2006)
> It seems encoding was broken some how.
Encoding is just fine. That's UTF-8 for en-dash. Should've used an
entity, though; will fix.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. br...@wandisco.com
act/a0a022ce-26d5-4934-bce4-ea8e6a66ad2b HTTP/1.1"
>> 204 - Length:-
>>
>> so all the requests you show appeared to work. The client should have
>> gone on to do HEAD, PUT, PUT, PUT but something caused it to abort the
>> commit and send a DELETE instead.
> Agreed, it is very weird, not even sure where to look. Not only did I
> consistently get this problem on repeated attempts to commit, but I
> switched from Windows to Mac, did a new checkout and got same error
> when trying to commit again.
>
> I needed to do this commit, so I have since done it using 1.7 and
> Neon. 1.7 and Serf failed with APR error code unknown, which I assume
> was the "The server sent a truncated HTTP response body" error.
Might there possibly be an HTTP/1.0 proxy at work here?
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. br...@wandisco.com
Given the number of reports on users@, I think we have to get a 1.8.1
with /only/ the 'svnadmin upgrade' crash fix out ASAP.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. br...@wandisco.com
On 19.06.2013 11:00, Branko Čibej wrote:
> Given the number of reports on users@, I think we have to get a 1.8.1
> with /only/ the 'svnadmin upgrade' crash fix out ASAP.
(a.k.a I can try to botch the RM if there's agreement on this.)
--
Branko Čibej | Director of Subversion
am
> asking for more explanation. Surely this cannot be what you are
> saying?
>
> We can all agree we have a significant number of existing users using
> an automatic authentication method with Windows. I am calling that
> mod_auth_sspi. I guess to use your terms, that means NTLM. Are any
> of these users using the SSPI negotiate option? If our pre-1.8
> clients do not support that option then I would have to say No.
>
> I fail to see how you can justify a veto here.
I have to agree. The veto is fine on aesthetic grounds but kind of fails
to take account of reality.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. br...@wandisco.com
e Makefile.
Yup.
> On Solaris that means "turn off any non c90 features". If you want all
> of the c90 compatible extensions on top of c90, then you need to define
> __EXTENSIONS__.
Could you provide a patch that does that? I expect the best place would
be in the SVN_CC_
On 20.06.2013 22:30, Branko Čibej wrote:
> On 20.06.2013 17:52, Rainer Jung wrote:
>> 1.8.0 calls gcc with -std=c90. For my Solaris 10 Sparc using gcc 4.7.2
>> this leads to "_STRICT_STDC" getting defined and then limits.h no longer
>> defines PATH_MAX. So apr.
nical thoughts are fair and
> related to technical issues only. My veto above is a technical veto.
Yep, it was. And I still maintain it's invalid, or at least, too naïve.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. br...@wandisco.com
On 20.06.2013 23:17, Rainer Jung wrote:
> On 20.06.2013 22:38, Branko Čibej wrote:
>> On 20.06.2013 22:30, Branko Čibej wrote:
>>> On 20.06.2013 17:52, Rainer Jung wrote:
>>>> 1.8.0 calls gcc with -std=c90. For my Solaris 10 Sparc using gcc 4.7.2
>>>> th
ts (as the first Driving Order Restriction) that there must
> be an alter_directory call for the parent of moved-away node 'A/B'. What
> does this look like?
>
> alter_dir('A', ...)
>
> or
>
> alter_dir('A2', ...)
>
> ? Can the alter_dir come before or after the move of 'A' to 'A2'? Is the
> path it references 'A' in either case, or 'A2' in either case, or 'A' if it
> comes before the move and 'A2' if it comes after the move?
>
> Can we start with a clear consensus of whether we're trying to deliver a
> sequential or a parallel editor?
Both :)
However I am a bit worried that the "once rule", as stated, is always
broken in the case you describe.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. br...@wandisco.com
On 24.06.2013 17:52, Branko Čibej wrote:
> You're breaking the once rule here.
>
> And the case you're describing can never occur. You cannot have a
> working copy that describes what you're doing. Tree mutations can only
> be parallelized across distinct subtrees
On 24.06.2013 18:00, Daniel Shahaf wrote:
> Branko Čibej wrote on Mon, Jun 24, 2013 at 16:32:56 +0200:
>> On 24.06.2013 11:46, Daniel Shahaf wrote:
>>> Branko Čibej wrote on Sat, Jun 22, 2013 at 18:02:32 +0200:
>>>> On 22.06.2013 17:46, Nico Kadel-Garcia wrote:
>&
t's more, when we create a new working copy, we
create those files, too.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. br...@wandisco.com
On 24.06.2013 23:52, Branko Čibej wrote:
> On 24.06.2013 23:24, Daniel Shahaf wrote:
>> % /usr/local/svn-1.7.1/bin/svn co -q
>> https://svn.apache.org/repos/asf/subversion/trunk/notes/commit-access-templates/
>> % ls commit-access-templates/.svn
>> entries format pr
On 25.06.2013 00:03, Branko Čibej wrote:
> On 24.06.2013 23:52, Branko Čibej wrote:
>> On 24.06.2013 23:24, Daniel Shahaf wrote:
>>> % /usr/local/svn-1.7.1/bin/svn co -q
>>> https://svn.apache.org/repos/asf/subversion/trunk/notes/commit-access-templates/
>>&g
t. This should provide workaround for current
>> users. And then continue discussion about full/automatic solution.
>>
> Added 'htttp-chunked-requests' configuration in r1496470.
I'm really not a fan of this config knob. Anyone who carries their
laptop around will effecti
that a quorum? :)
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. br...@wandisco.com
gt; moved to wc/A/B
D +wc/X/Y/Z/B/C
Hm it would appear that EV2 rotate needs the concept of virtual
temporary nodes in order to represent something like the above.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. br...@wandisco.com
b (now)
and show just the differences between the old and new locations of the
renamed file, and afterwards issue a "delete" diff for 'a'; but that's
just an optimization (and not all versions of patch may actually get
that right).
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. br...@wandisco.com
> svn mv A B; svn mv B/C D; svn ci;
>
> which could be represented in Ev2 as:
>
> move(A, B); move(B/C, D);
>
> or as:
>
> move(A/C, D); move(B, D);
>
> It's not clear to me yet which of the two options is preferred, or whether
> there are more options.
Th
ng up A2 or X2, as in Philip's original email. The
>> commit process is not creating nodes that exist only during the txn.
>> All nodes survive the txn.
> X2 was a temporary name. A/B/C/Y is a temporary name. Neither the name
> X2 nor the name A/B/C/Y survives the txn.
You&#
due to the Once Rule: every
> node is the destination of exactly one editor call.
That's not what the Once Rule says; and if you think about it, it's
impossible unless move and copy get contents/props arguments just like
add and alter.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. br...@wandisco.com
rue moves that do not apply to the copy+delete model
(an obvious example being that you can't commit only half a move).
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. br...@wandisco.com
swapping all the children of the
rotated nodes, which is decidedly not a single operation. Reducing the
result of such an operation to your childless rotate is of course
possible, but IMO makes no sense because the situation too rare.
In other words, if rotate were defined to operate on nodes without
children, you'd almost never actually use it.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. br...@wandisco.com
On 27.06.2013 20:29, Branko Čibej wrote:
> We are talking here about optimizing the number of operations required
> to reproduce a tree state. Some sequences of operations are irreducible
> -- so it doesn't help to invent such sequences and then try to define
> "rotate"
about.
> The svn:special design is horrible. For backwards compat and wire
> protocol purposes, we'll always have to deal with it, but we can fix
> our top-level APIs.
That depends on what you call a top-level API; mine for symlinks is
called "ln" :)
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. br...@wandisco.com
Philip, can you please take another look at the r1469519 series proposal
in the 1.8.x STATUS file? I think your objection no longer holds after I
restructured the code.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. br...@wandisco.com
> ~/.subversion/servers for Linux), and add the option "http-compression = no"
> either globally or on the affected servers.
Thanks. It's already fixed on trunk and will be in 1.8.1.
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. br...@wandisco.com
ilities and selecting
the correct wrapper editor for the peer. I suspect it's even RA-layer
independent.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. br...@wandisco.com
suitable alternate to use of mmap in named_atomic.c in the foreseeable
> future?' or have I arrived at the end of the branch?
Looks like it could be fixed, as the code does have an explicit check
for named atomic support; it just doesn't use the APR_HAS_MMAP flag as
well. Can you try the a
at
> should the end of the blame chain be --- file@r30, file@r20, or file@r10?
I'd expect that to depend on whatever happens to be the peg revision in
the blame incantation. I can never remember what the default is in any
particular case.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. br...@wandisco.com
as Greg pointed out, Serf bugs are not Subversion
bugs. There are a number of important fixes ready for 1.8.1 that do not
depend on Serf.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. br...@wandisco.com
On 01.07.2013 20:07, Daniel Shahaf wrote:
> Branko Čibej wrote on Mon, Jul 01, 2013 at 19:41:10 +0200:
>> On 01.07.2013 19:36, Daniel Shahaf wrote:
>>> Thinking about the behaviour of 'svn blame -r 50:20 file@50':
>>>
>>> Right now, if I'm not
t use the console codepage during
output, it uses the ANSI codepage. These are not always the same, as was
discussed on users@.
The issue has been known for a long time; see:
http://subversion.tigris.org/issues/show_bug.cgi?id=1537
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop D
new symbolic and
enumerated constants, and deprecate existing functions.
I was very careful to check that before introducing the the new
enumeration. It's not as if this is a new rule. (And yes ... I did weigh
the pros and cons of doing that. The cons included a choice between
revving
trepo' failed to
> verify
The last message ("failed to verify") is not specific to revision 6;
that it's attached to the list of corrupt revisions is extremely
confusing. IMO it should be something like:
svnadmin: E165011: Repository '/tmp/testrepo' failed to verify
Summary of corrupt revisions:
Revision 2: E160004: Final line in revision file r2 missing space
Revision 4: E160004: Invalid change kind in rev file
Revision 6: E160004: Final line in revision file r6 missing space
Repeating the svnadmin: prefix in the summary seems unnecessary.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. br...@wandisco.com
error codes differently,
and it's a bad idea to make them parse it out.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. br...@wandisco.com
t;
> # Look for libdb4.so first:
> SVN_LIB_BERKELEY_DB($SVN_FS_WANT_DB_MAJOR, $SVN_FS_WANT_DB_MINOR,
> $SVN_FS_WANT_DB_PATCH, [db4 db])
> @@ -1516,7 +1517,7 @@ if test "$svn_lib_berkeley_db" = "no" && test "$wi
>AC_MSG_WARN([we have configured without BDB filesystem support
>
>
> -You don't seem to have Berkeley DB version $db_version or newer
> +You don't seem to have Berkeley DB version $db_version or $db_alt_version
> installed and linked to APR-UTIL. We have created a Makefile which will
> build
> Subversion without support for the Berkeley DB back-end. You can find the
> latest version of Berkeley DB here:
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. br...@wandisco.com
t; will arrive.
With Subversion, Serf and HTTPv2, you can predict that, and the
"slightly increased latency" has a much larger impact on performance.
This was demonstrated any number of times during ra_serf development.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. br...@wandisco.com
On 03.07.2013 16:07, Branko Čibej wrote:
> I do have a comment; it specifically assumes the clients are browsers,
... and that the servers host web sites; important distinction there, too.
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. br...@wandisco.com
t the bulk-mode workaround exists in part as a
workaround for that, effectively disabling the more efficient HTTPv2
protocol.
In the meantime, it might be a good idea to relax the restrictions in
git-svn to account for the way the HTTPv2 protocol works.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. br...@wandisco.com
ould be obvious.
> Thx!
You're welcome. :)
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. br...@wandisco.com
-picked to 1.8.x, and I make a
wholesale sync from 1.8.x to the JavaHL extensions branch. The trunk
mergeinfo is inherited from the 1.8.x branch.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. br...@wandisco.com
me kind of workaround" I mean "a fix that does not
require users to edit their config files."
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. br...@wandisco.com
s a specific
> set of APR defined error codes that are handled specificly in serf).
Daniel said this a number of times: The Serf API (and, as a consequence,
Serf's error codes) are not part of our public API. Why then should we
leave those error codes unwrapped? We wrap everything else, including Win32.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. br...@wandisco.com
;t
object to extracting the Serf error message and adding a "caused-by:
serf error " in the same error chain.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. br...@wandisco.com
VN, non-APR messages at the top of the error stack.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. br...@wandisco.com
quot;busted" proxies. It's fine to print a big fat warning
that some host is behind a proxy that doesn't support such-and-such a
feature of the HTTP protocol which will make their latency suck; they
can go complain to the site admins. It's not fine to tell them to fiddle
with t
On 10.07.2013 05:43, Greg Stein wrote:
> On Tue, Jul 9, 2013 at 10:50 PM, Branko Čibej wrote:
>> On 09.07.2013 05:53, Greg Stein wrote:
>> ...
>>> For *this* project, that is absolutely the case. We have never said
>>> "let's work against any server any
On 10.07.2013 10:20, Branko Čibej wrote:
> On 10.07.2013 05:43, Greg Stein wrote:
>> On Tue, Jul 9, 2013 at 10:50 PM, Branko Čibej wrote:
>>> On 09.07.2013 05:53, Greg Stein wrote:
>>> ...
>>>> For *this* project, that is absolutely the case. We have never s
rch path.
Did we? I thought we'd decided on lockstep for libraries, and for
direct-access tools such as svnadmin and svnlook. Don't recall requiring
the same for the client. On the other hand ... the client does use
private APIs.
-- Brane
--
Branko Čibej | Director of Subversion
WANd
T of large files and/or deltas, IIRC -- but
those shouldn't have to be retried if the probe does the right thing.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. br...@wandisco.com
801 - 900 of 2896 matches
Mail list logo
