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 them:
>
> [[[
> cp iota iota.bak
> echo "modified" > iota
> SVN_EDITOR='f(){ mv iota.bak iota; echo logmsg > $1; }; f' svn ci
> ]]]
Right -- I presume the client then commits a no-op change for file 'iota'.
That's one effect of the way the client scans the WC first to determine the
list of paths to be committed (no-change files are excluded, but 'iota' at this
stage has a change), then waits to get a log message, then reads the WC again
to calculate the actual change to send for each path (and now 'iota' has no
change). This general behaviour affects more than just no-op changes, of
course: if you apply a patch to several files while editing the log message,
some of the patched files might be committed (those that were already modified
at the invocation of the commit command) and others not.
Philip Martin wrote:
> Julian Foad writes:
>> [[[
>> $ svn diff --summarize -c6 $REPO
>> [no output]
>>
>> $ svn log -vq --xml -r6 $REPO
>> <... prop-mods="true">/trunk</path>
>> ]]]
>>
>> This output says that there was a property "modification" in r6
>> ... and yet shows no changes.
>
> The diff output is partly a choice made by the client itself. If we
> operate on a non-root node:
>
> svnadmin create repo
> svn mkdir -mm file://`pwd`/repo/A
> svnmucc -mm -U put repo/format file://`pwd`/repo/A/f
> svnmucc -mm -U put repo/format file://`pwd`/repo/A/f
> svnmucc -mm -U propel p file://`pwd`/repo/A
>
> The diff reports that the server sends to the client include an open-dir
> for /A in -c3 and an open-file for /A/f in -c4.
(I think you mean the other way around -- the open-file for /A/f is in -c3.)
> 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".) You have observed this correlation
between new node-revs and editor method calls in the current typical Subversion
software configuration. The client should not assume that an "open-dir" or
"open-file" editor method call means a new node-revision in the file system.
Node-revisions are meant to be a private implementation detail of the repos or
FS layers.
> 'svnlook changed' has behaviour that is somewhere between log and diff
> above: it indicates a change for for the text no-op -r3 but no change
> for the property no-op -r4.
Heh, nice observation.
- Julian
