On 15.10.2019 09:10, Julian Foad wrote:
> Branko Čibej wrote:
>> [...] if the dump or the load step drops no-op
>> changes, all existing working copies suddenly are no longer compatible
>
> No. They remain compatible.
>
> (Perhaps you are thinking of eliminating no-op commits and renumbering re
Branko Čibej wrote:
> [...] if the dump or the load step drops no-op
> changes, all existing working copies suddenly are no longer compatible
No. They remain compatible.
(Perhaps you are thinking of eliminating no-op commits and renumbering revs.
That's not what we're talking about.)
- Jul
On 14.10.2019 10:07, Johan Corveleyn wrote:
> On Fri, Oct 11, 2019 at 4:56 PM Julian Foad wrote:
> ...
>> Some of the existing svn protocols and APIs explicitly preserve certain
>> no-op changes. For example, one user reported [2] that in their svn
>> history (converted from CVS) they would "hate
Eric S. Raymond wrote:
> Then I no longer undersrand what we are talking about.
OK, no worries. I was just hoping you'd twig what I'm clumsily trying to get
at, but I'll have to write it up properly some time.
- Julian
Julian Foad :
> Eric S. Raymond wrote:
> > Julian Foad :
> > > [...] I have come across a number of kinds of what could
> > > be called a "no-op change" or perhaps better described as "I touched this
> > > but did not change its value".
> [...]
> > No-op commits are specifically awkward for
> [...
Eric S. Raymond wrote:
Julian Foad :
[...] I have come across a number of kinds of what could
be called a "no-op change" or perhaps better described as "I touched this
but did not change its value".
[...]
No-op commits are specifically awkward for
[...]
Eric, thank you for your thoughts on
On Fri, Oct 11, 2019 at 4:56 PM Julian Foad wrote:
...
> Some of the existing svn protocols and APIs explicitly preserve certain
> no-op changes. For example, one user reported [2] that in their svn
> history (converted from CVS) they would "hate to lose" the historical
> record that "svn log -v"
Julian Foad :
> Hello Eric.
>
> TL;DR: I explain why I am convinced no-op changes don't belong in the
> Subversion versioning semantics. With your work on Subversion repository
> and dump stream semantics, is this something you can offer a view on? I
> have previously failed to convince the dev
;», or even «foo; ;».
It is not a syntax error. It _will_ generate a compiler warning, but
you will be able to compile and run it.
Similarly, I suspect "no no-op changes" is a semantic that belongs at
the same level as "no mixed-revision or switched subtrees": it is
something a use
as simple as declaring one version as the canonical form, or
may require further travel down the road of copy-from semantics.
In conclusion, I consider svn would be a better system -- more
predictable, testable, composable, etc.; more generally dependable --
and would lose no significant value
Daniel Shahaf wrote:
> Should we provide an "official" way to create an empty revision? That
> is, a revision whose changed-paths list is empty? [...]
I replied to this in a new thread, "Official way to create an empty revision".
- Julian
Julian Foad wrote on Fri, Sep 19, 2014 at 16:34:04 +0100:
> Andreas Stieger wrote:
> >> Julian Foad wrote:
> >> Summary:
> >> * A "no-op change" is not a change.
> >> * Subversion should not report a "no-op change" as a "change".
> >> * We should bear this in mind when designing and revie
On Mon, Sep 22, 2014 at 1:40 PM, C. Michael Pilato
wrote:
> On 09/22/2014 12:13 PM, Julian Foad wrote:
> > Yup. So let's say we can agree to hide this behaviour at the repos
> layer. Then we face the decision of what to do with the FS layer:
> >
> > * make FS layer consistently version no-ops
>
On 09/22/2014 12:13 PM, Julian Foad wrote:
> Yup. So let's say we can agree to hide this behaviour at the repos layer.
> Then we face the decision of what to do with the FS layer:
>
> * make FS layer consistently version no-ops
> -- a lot of work at FS layer
> -- some work at repos layer
Philip Martin wrote:
> Julian Foad writes:
>>> The diff reports have
>>> no equivalent of log's text-mods/props-mods but they do communicate that
>>> a new node was created. The diff client could choose to output some
>>> sort of "new node" message.
>>
>> (I assume you mean "new node-revision".
Julian Foad writes:
>> The diff reports have
>> no equivalent of log's text-mods/props-mods but they do communicate that
>> a new node was created. The diff client could choose to output some
>> sort of "new node" message.
>
> (I assume you mean "new node-revision".)
More that the client could
Thanks for the additional examples of the inconsistencies, Philip and Daniel.
Daniel Shahaf wrote:
> Julian Foad wrote on Mon, Sep 22, 2014 at 09:43:22 +0100:
>> * You can't commit any no-op change using 'svn'.
>>
>> Except possibly for one or two remaining obscure bugs.
>
> This is one of the
C. Michael Pilato wrote:
> On 09/22/2014 11:04 AM, Julian Foad wrote:
>> Would you accept that it now makes more sense to make the overall
>> system behaviour more consistent by moving towards the majority
>> direction (not preserving no-ops)? At least at some layers -- repos
>> layer or RA lay
Julian Foad writes:
> [[[
> $ svn propget p $REPO/trunk -r5
> v
>
> $ svnmucc -U file://$PWD/repo -m "" propset p v trunk
> r6 committed ...
>
> $ svn diff --summarize -c6 $REPO
> [no output]
>
> $ svn log -vq --xml -r6 $REPO
> <...>
> kind="dir"
> action="M"
> text-mods="false"
>
On 09/22/2014 11:04 AM, Julian Foad wrote:
> Would you accept that it now makes more sense to make the overall
> system behaviour more consistent by moving towards the majority
> direction (not preserving no-ops)? At least at some layers -- repos
> layer or RA layer?
"At least at some layers", yes
C. Michael Pilato wrote:
> On 09/20/2014 03:56 AM, Branko Čibej wrote:
>> We should do exactly the opposite! We should make sure that even no-op
>> changes
>> always get recorded and reported consistently. [...]
>
> FWIW, this line of thought is consistent with the original FS
> backend and dump/
On 09/20/2014 03:56 AM, Branko Čibej wrote:
> We should do exactly the opposite! We should make sure that even no-op
> changes always get recorded and reported consistently. You have to
> remember that repository history is not only about tree snapshots,
> it's also about intent and results. In oth
Greg Stein wrote:
> Branko Čibej wrote:
>> We should do exactly the opposite! We should make sure that even no-op
>> changes
>> always get recorded and reported consistently. [...]
>
> Agreed.
Hi Greg.
> When you start including ACLs, then r1234 might look different to two people.
A revision c
Julian Foad wrote on Mon, Sep 22, 2014 at 09:43:22 +0100:
> * You can't commit any no-op change using 'svn'.
>
> Except possibly for one or two remaining obscure bugs.
This is one of them:
[[[
cp iota iota.bak
echo "modified" > iota
SVN_EDITOR='f(){ mv iota.bak iota; echo logmsg > $1; }; f' sv
Branko Čibej wrote:
> On 19.09.2014 16:49, Julian Foad wrote:
>> $ svn diff --summarize -c6 $REPO
>> [no output]
>> $ svn log -vq --xml -r6 $REPO
>> <... prop-mods="true">/trunk
>>
>> This output says that there was a property "modification" in r6 ... and yet
>> shows no changes.
>
> I really don
On Sat, Sep 20, 2014 at 2:56 AM, Branko Čibej wrote:
>...
> We should do exactly the opposite! We should make sure that even no-op
> changes always get recorded and reported consistently. You have to remember
> that repository history is not only about tree snapshots, it's also about
> intent an
On 19.09.2014 16:49, Julian Foad wrote:
> Summary:
> * A "no-op change" is not a change.
> * Subversion should not report a "no-op change" as a "change".
> * We should bear this in mind when designing and reviewing.
> * Fixes are needed in a few places.
>
> I noticed recently that we handle
Bert Huijben wrote:
[...]
> I'm not sure at which layer this is a bug, as the filesystem layer is pretty
> consistent. I think I would say that the repos layer should catch this
> case...
Actually it is a FS layer problem. svn_fs_paths_changed2() returns paths which
have in fact not had a change
> -Original Message-
> From: Julian Foad [mailto:julianf...@btopenworld.com]
> Sent: vrijdag 19 september 2014 16:50
> To: dev@subversion.apache.org
> Cc: Stefan Fuhrmann
> Subject: No no-op changes
>
> Summary:
> * A "no-op change" is not a chang
Andreas Stieger wrote:
>> Julian Foad wrote:
>> Summary:
>> * A "no-op change" is not a change.
>> * Subversion should not report a "no-op change" as a "change".
>> * We should bear this in mind when designing and reviewing.
>> * Fixes are needed in a few places.
>
> These no-op chang
> On 19 Sep 2014, at 15:49, Julian Foad wrote:
>
> Summary:
> * A "no-op change" is not a change.
> * Subversion should not report a "no-op change" as a "change".
> * We should bear this in mind when designing and reviewing.
> * Fixes are needed in a few places.
These no-op change scena
Summary:
* A "no-op change" is not a change.
* Subversion should not report a "no-op change" as a "change".
* We should bear this in mind when designing and reviewing.
* Fixes are needed in a few places.
I noticed recently that we handle "no-op changes" inconsistently. By a "no-op
change"
32 matches
Mail list logo
