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 change.
> * Subversion should not report a
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
21 matches
Mail list logo
