Norbert Preining wrote on Tue, Oct 31, 2017 at 09:34:08 +0900:
> > Fixed in https://svn.apache.org/r1813794 and nominated for backport
> > to 1.9.8. Pizzas to stsp :-)
>
> Thanks a lot.
>
> With a fixed/updated subversion client, will I get the updates
> automatically, or do I need also an updat
> Fixed in https://svn.apache.org/r1813794 and nominated for backport
> to 1.9.8. Pizzas to stsp :-)
Thanks a lot.
With a fixed/updated subversion client, will I get the updates
automatically, or do I need also an updated server, and also do some
special svn up invocations?
Best
Norbert
--
PR
Stefan Sperling wrote on Mon, 30 Oct 2017 15:57 +0100:
> On Mon, Oct 30, 2017 at 02:49:21PM +, Daniel Shahaf wrote:
> > Stefan Sperling wrote on Mon, 30 Oct 2017 15:30 +0100:
> > > It looks like a bug. The last-changed revision of the file is not
> > > bumped even though it should be. It seems
Hi everyone
thanks for the incredible quick check and ACK.
> Norbert, congratulations, you found a bug that we'd all have expected to
> be impossible. Regarding the "what were we thinking" rant in your blog;
> clearly, we were thinking that this bug could not possibly have crept
> through all our
On 30.10.2017 15:49, Daniel Shahaf wrote:
> Stefan Sperling wrote on Mon, 30 Oct 2017 15:30 +0100:
>> It looks like a bug. The last-changed revision of the file is not
>> bumped even though it should be. It seems to be related to the
>> fact that the server does not send a delta for the file during
On Mon, Oct 30, 2017 at 02:49:21PM +, Daniel Shahaf wrote:
> Stefan Sperling wrote on Mon, 30 Oct 2017 15:30 +0100:
> > It looks like a bug. The last-changed revision of the file is not
> > bumped even though it should be. It seems to be related to the
> > fact that the server does not send a d
Stefan Sperling wrote on Mon, 30 Oct 2017 15:30 +0100:
> It looks like a bug. The last-changed revision of the file is not
> bumped even though it should be. It seems to be related to the
> fact that the server does not send a delta for the file during
> client B's update because the file's content
On Mon, Oct 30, 2017 at 03:11:20PM +0100, Branko Čibej wrote:
> On 30.10.2017 14:54, Norbert Preining wrote:
> > Dear all,
> >
> > (please Cc, I am not subscribed)
> >
> > I have blogged about this [1] and both Branko Čibej and Stefan Sperling
> > asked me to move the discussion here.
> > [1]
> >
Hi Branko,
> > * both checkout are completely clean, no out-of-vcs files, no
> > ignored files, no mixed revisions, dead plain svn checkouts.
>
> I'm pretty sure they're not, but see below.
Disprove me, please!
> > My assumption *was* that this is *consistent* across checkout, but it is
> > n
On 30.10.2017 14:54, Norbert Preining wrote:
> Dear all,
>
> (please Cc, I am not subscribed)
>
> I have blogged about this [1] and both Branko Čibej and Stefan Sperling
> asked me to move the discussion here.
> [1]
> https://www.preining.info/blog/2017/10/inconsistent-version-numbers-in-subversio
Dear all,
(please Cc, I am not subscribed)
I have blogged about this [1] and both Branko Čibej and Stefan Sperling
asked me to move the discussion here.
[1]
https://www.preining.info/blog/2017/10/inconsistent-version-numbers-in-subversion/
I describe my problem
* Assume a subversion server and
11 matches
Mail list logo
