On 26.10.2015 17:45, Evgeny Kotkov wrote:
Stefan Fuhrmann writes:
As for /trunk, I think that we could do that, so I sketched this option in
the attached patch.
The patch looks o.k.
Thanks for giving this patch a look.
I examined the differences between these functions, svn_repos__compare_f
Evgeny Kotkov writes:
> Since this discussion has been lasting for over a month now, I proposed
> what I believe is the proper solution for the problem (and that's (1) )
> in /branches/1.9.x/STATUS.
After giving it more thought, I agree that changing other cases isn't required
and justified in c
On 29.10.2015 17:13, Evgeny Kotkov wrote:
> Julian Foad writes:
>
>> If the state has been "well defined", then please point us to the
>> definition of it, or to the tests that confirm it works as defined. If
>> you can't, then the state has not been "well defined". All we can say
>> is it has bee
Julian Foad writes:
> If the state has been "well defined", then please point us to the
> definition of it, or to the tests that confirm it works as defined. If
> you can't, then the state has not been "well defined". All we can say
> is it has been "unchanged" over a long period of time.
Okay,
Evgeny, part of the problem is this:
Evgeny Kotkov wrote:
> Bert Huijben writes:
>> I'm just -0.9 on reverting the rest 'as it *may* have problems too'.
>
> Perhaps I was not clear on my motivation, so here is how I see it.
>
> We had state A, and it has been well-defined during many consecutive
Bert Huijben writes:
> I'm just -0.9 on reverting the rest 'as it *may* have problems too'.
Perhaps I was not clear on my motivation, so here is how I see it.
We had state A, and it has been well-defined during many consecutive releases.
Then we made an arbitrary change that transitioned everyt
Evgeny Kotkov wrote:
> Bert Huijben writes:
>> But this 'go back to 1.8' suggestio changes Subversion everywhere. It will
>> make 'svn annotate' slower... Makes 'svn update' slower and report more tree
>> conflicts, etc. etc.
>
> For 'svn blame', the only difference is that we would be processing
> -Original Message-
> From: Evgeny Kotkov [mailto:evgeny.kot...@visualsvn.com]
> Sent: dinsdag 27 oktober 2015 14:38
> To: Bert Huijben
> Cc: Johan Corveleyn ; Stefan Fuhrmann
> ; Julian Foad
> ; dev
> Subject: Re: No-op changes no longer dumped by 'svnadm
Bert Huijben writes:
> But this 'go back to 1.8' suggestio changes Subversion everywhere. It will
> make 'svn annotate' slower... Makes 'svn update' slower and report more tree
> conflicts, etc. etc.
For 'svn blame', the only difference is that we would be processing no-op
changes in file histor
>>
>>
>>> -Original Message-
>>> From: Evgeny Kotkov [mailto:evgeny.kot...@visualsvn.com]
>>> Sent: maandag 26 oktober 2015 17:45
>>> To: Bert Huijben ; Stefan Fuhrmann
>>>
>>> Cc: Johan Corveleyn ; Julian Foad
>>> ; dev
...@qqmail.nl [mailto:b...@qqmail.nl]
Sent: dinsdag 27 oktober 2015 08:44
To: Johan Corveleyn
Cc: Evgeny Kotkov ; Stefan Fuhrmann
; Julian Foad ; dev
Subject: RE: No-op changes no longer dumped by 'svnadmin dump' in 1.9
But as Julian and Branko pointed out Subversion's update ope
dinsdag 27 oktober 2015 02:53
To: Bert Huijben
Cc: Evgeny Kotkov;Stefan Fuhrmann;Julian Foad;dev
Subject: Re: No-op changes no longer dumped by 'svnadmin dump' in 1.9
Bert,
As the OP of this mail-thread, which spun out of the discovery of a
loss of information by 'dump' in 1.9 [1
m]
>> Sent: maandag 26 oktober 2015 17:45
>> To: Bert Huijben ; Stefan Fuhrmann
>>
>> Cc: Johan Corveleyn ; Julian Foad
>> ; dev
>> Subject: Re: No-op changes no longer dumped by 'svnadmin dump' in 1.9
>
>
>> This means that after r1572363 a
> -Original Message-
> From: Evgeny Kotkov [mailto:evgeny.kot...@visualsvn.com]
> Sent: maandag 26 oktober 2015 17:45
> To: Bert Huijben ; Stefan Fuhrmann
>
> Cc: Johan Corveleyn ; Julian Foad
> ; dev
> Subject: Re: No-op changes no longer dumped by 's
Bert Huijben writes:
> Noting everything as a change even if there is no actual delta... still
> looks like a bug we should fix (and we did) instead of something that we
> should restore.
>
> For the reasoning on why:
>
> For blame we are really interested if there are deltas... and if there
> ar
On Wed, Oct 21, 2015 at 2:21 PM, Evgeny Kotkov
wrote:
> Stefan Fuhrmann writes:
>
> > Could you at least use the new API in svn_repos__compare_files instead
> > of re-implementing parts of the FS back-end but worse? I know this is
> > the code as it has been in 1.8 but that does not make the it
To: Stefan Fuhrmann
Cc: Johan Corveleyn;Julian Foad;dev
Subject: Re: No-op changes no longer dumped by 'svnadmin dump' in 1.9
Stefan Fuhrmann writes:
> Could you at least use the new API in svn_repos__compare_files instead
> of re-implementing parts of the FS back-end but worse?
Stefan Fuhrmann writes:
> Could you at least use the new API in svn_repos__compare_files instead
> of re-implementing parts of the FS back-end but worse? I know this is
> the code as it has been in 1.8 but that does not make the it any better.
Speaking of /branches/1.9.x, I would like to nominat
On Mon, Oct 19, 2015 at 1:06 PM, Evgeny Kotkov
wrote:
> Evgeny Kotkov writes:
>
> > Irrespectively of what we plan for 1.10, there's a problem in a 1.9 that
> we
> > need to solve. The associated issues are hard to diagnose and hard to
> > stumble upon, and I don't think that fixing them one by
Evgeny Kotkov writes:
> Irrespectively of what we plan for 1.10, there's a problem in a 1.9 that we
> need to solve. The associated issues are hard to diagnose and hard to
> stumble upon, and I don't think that fixing them one by one as we become
> aware of their existence is a way to go, as opp
Johan Corveleyn writes:
> I don't know if a full revert, or a forward-working fix is the best
> course of action. The immediate concern for me is fixing the
> regression of losing no-op change information in dumps. Perhaps if
> stefan2's work can be fitted in the larger picture of a design such a
On Wed, Oct 14, 2015 at 6:53 PM, Julian Foad wrote:
> All,
>
> Please see the email I've just sent, entitled "Changes, Differences,
> and States". I wanted to put down some thoughts and that's the best I
> can do in the time. I hope it may shed a few glimmers of light in this
> area.
Thanks, Juli
All,
Please see the email I've just sent, entitled "Changes, Differences,
and States". I wanted to put down some thoughts and that's the best I
can do in the time. I hope it may shed a few glimmers of light in this
area.
- Julian
On 14 October 2015 at 16:37, Evgeny Kotkov wrote:
> Stefan Fuhrm
n.haxx.se/dev/archive-2015-06/0069.shtml, "Blame behaviour
change in 1.9").
- We have an issue with repositories behaving differently in client-side
operations like 'svn log' after dump/load
(http://svn.haxx.se/dev/archive-2015-09/0269.shtml, "No-op changes no
On Thu, Oct 8, 2015 at 1:07 PM, Evgeny Kotkov
wrote:
> Stefan Fuhrmann writes:
>
> > This is not about performance, it is about API guarantees and functional
> > stability. So, yes that is an optimization in the sense of "making it
> better
> > than before". And no, we should not go back to wors
Stefan Fuhrmann writes:
> This is not about performance, it is about API guarantees and functional
> stability. So, yes that is an optimization in the sense of "making it better
> than before". And no, we should not go back to worse unless there is no other
> practical way.
Exactly how does this
On Sun, Oct 4, 2015 at 4:28 PM, Evgeny Kotkov
wrote:
> Stefan Fuhrmann writes:
>
> > Right now, we are losing information. In rare cases and probably nothing
> too
> > important but still. This aspect makes me consider the current behaviour
> a
> > bug. Whether creating that situation in the fir
Stefan Fuhrmann writes:
> Right now, we are losing information. In rare cases and probably nothing too
> important but still. This aspect makes me consider the current behaviour a
> bug. Whether creating that situation in the first place was o.k. nor not is
> a separate issue.
To my mind, the cu
On Tue, Sep 29, 2015 at 3:09 PM, Julian Foad wrote:
> Thanks for the comments, Stefan.
>
> Stefan Fuhrmann wrote:
> > On Mon, Sep 28, 2015, Stefan Fuhrmann wrote:
> >> I suggest that we apply the patch below. It is more efficient
> >> that the original behaviour but ensures that "no-op" changes
>
Thanks for the comments, Stefan.
Stefan Fuhrmann wrote:
> On Mon, Sep 28, 2015, Stefan Fuhrmann wrote:
>> I suggest that we apply the patch below. It is more efficient
>> that the original behaviour but ensures that "no-op" changes
>> will be retained.
>
> Now that I've read through the whole thre
On Tue, Sep 29, 2015 at 1:47 PM, Stefan Fuhrmann
wrote:
> On Mon, Sep 28, 2015 at 10:55 AM, Stefan Fuhrmann
> wrote:
>>
>> On Wed, Sep 23, 2015 at 12:55 PM, Julian Foad
>> wrote:
>>>
>>> > Johan Corveleyn wrote:
>>> >> [...] stefan2 told me in person that that part of the
>>> >> change in r15723
On Mon, Sep 28, 2015 at 10:55 AM, Stefan Fuhrmann <
stefan.fuhrm...@wandisco.com> wrote:
> On Wed, Sep 23, 2015 at 12:55 PM, Julian Foad
> wrote:
>
>> > Johan Corveleyn wrote:
>> >> [...] stefan2 told me in person that that part of the
>> >> change in r1572363 was unintentional :-). IIUC, he didn
On Wed, Sep 23, 2015 at 12:55 PM, Julian Foad
wrote:
> > Johan Corveleyn wrote:
> >> [...] stefan2 told me in person that that part of the
> >> change in r1572363 was unintentional :-). IIUC, he didn't realize that
> >> it would have this effect on the output of dump.
> [...]
> I think the d
I (Julian Foad) wrote:
> Issue #4598 "No-op changes no longer dumped by 'svnadmin dump' in
> 1.9", http://subversion.tigris.org/issues/show_bug.cgi?id=4598
>
> Added to the release notes in http://svn.apache.org/r1704822 :
> file:///home/julianfoad/src/svn-site/publish/docs/release-notes/1.9.html#n
Daniel Shahaf wrote on Wed, Sep 23, 2015 at 13:07:31 +:
> Julian Foad wrote on Tue, Sep 22, 2015 at 12:54:58 +0200:
> > Daniel Shahaf wrote:
> > > Johan Corveleyn wrote:
> > >> [...], revision N-1 contains a real
> > >> change, but only a short log message; and revision N has a no-op
> > >> cha
Johan Corveleyn wrote on Wed, Sep 23, 2015 at 11:03:43 +0200:
> Just one small addition on the fundamental part: I still think (like
> we discussed during breakfast last Friday in Berlin :-)) there is no
> problem in having / preserving / exposing null-text-changes to paths
> in Subversion.
I tend
Julian Foad wrote on Tue, Sep 22, 2015 at 12:54:58 +0200:
> Daniel Shahaf wrote:
> > Johan Corveleyn wrote:
> >> [...], revision N-1 contains a real
> >> change, but only a short log message; and revision N has a no-op
> >> change to that same path, and a very informative log message [...]
> >
> >
> Brane wrote:
>> I also suggest adding a note to
>> http://subversion.apache.org/docs/release-notes/1.9.html#issues .
>
> And we need to file an issue.
>
> I'll do both of those things (issue and rel-notes) now.
Issue #4598 "No-op changes no longer dumped by 'svnadmin dump' in
1.9", http://subver
On Wed, Sep 23, 2015 at 12:55 PM, Julian Foad
wrote:
>> Johan Corveleyn wrote:
>>> [...] stefan2 told me in person that that part of the
>>> change in r1572363 was unintentional :-). IIUC, he didn't realize that
>>> it would have this effect on the output of dump.
> [...]
> I think the dump.c
> Johan Corveleyn wrote:
>> [...] stefan2 told me in person that that part of the
>> change in r1572363 was unintentional :-). IIUC, he didn't realize that
>> it would have this effect on the output of dump.
[...]
I think the dump.c part of r1572363 and r1573111 should be reverted /
fixed
On 23.09.2015 11:58, Johan Corveleyn wrote:
> On Wed, Sep 23, 2015 at 11:44 AM, Branko Čibej wrote:
>> On 23.09.2015 11:03, Johan Corveleyn wrote:
>>> TBH, I'm not really interested in having a really fundamental
>>> discussion about this (but feel free to drive that of course). What I
>>> am inte
On Wed, Sep 23, 2015 at 11:44 AM, Branko Čibej wrote:
> On 23.09.2015 11:03, Johan Corveleyn wrote:
>> TBH, I'm not really interested in having a really fundamental
>> discussion about this (but feel free to drive that of course). What I
>> am interested in, is that we have a regression, and that
On 23.09.2015 11:03, Johan Corveleyn wrote:
> TBH, I'm not really interested in having a really fundamental
> discussion about this (but feel free to drive that of course). What I
> am interested in, is that we have a regression, and that 'dump' is
> losing information (namely, not dumping correctl
On Tue, Sep 22, 2015 at 12:54 PM, Julian Foad
wrote:
> Daniel Shahaf wrote:
>> Johan Corveleyn wrote:
>>> [...], revision N-1 contains a real
>>> change, but only a short log message; and revision N has a no-op
>>> change to that same path, and a very informative log message [...]
>>
>> The FreeBS
Daniel Shahaf wrote:
> Johan Corveleyn wrote:
>> [...], revision N-1 contains a real
>> change, but only a short log message; and revision N has a no-op
>> change to that same path, and a very informative log message [...]
>
> The FreeBSD project used to intentionally make no-op commits (they term
Johan Corveleyn wrote on Mon, Sep 21, 2015 at 16:38:20 +0200:
> In [jcorvel's company's] repository, there are a couple of such revisions,
> dating from
> our conversion from cvs to svn (actually, revision N-1 contains a real
> change, but only a short log message; and revision N has a no-op
> cha
On Mon, Sep 21, 2015 at 4:38 PM, Johan Corveleyn wrote:
...
> In our repository, there are a couple of such revisions, dating from
> our conversion from cvs to svn (actually, revision N-1 contains a real
> change, but only a short log message; and revision N has a no-op
> change to that same path,
47 matches
Mail list logo
