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/path
This output says that there was a property modification in r6 ... and yet
shows no changes.
I really don't see a problem
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
On 20 September 2014 12:11, Branko Čibej br...@wandisco.com wrote:
On 19.09.2014 17:21, i...@apache.org wrote:
Author: ivan
Date: Fri Sep 19 15:21:15 2014
New Revision: 1626247
URL: http://svn.apache.org/r1626247
Log:
Resolve another compiler warning.
* subversion/libsvn_ra_svn/client.c
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 can
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 other
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,
Julian Foad julianf...@btopenworld.com 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
...
path
kind=dir
action=M
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 layer?
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:
Julian Foad julianf...@btopenworld.com 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
Philip Martin wrote:
Julian Foad julianf...@btopenworld.com 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
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
Translation status report for trunk@r1626934
lang trans untrans fuzzy obs
--
de2754 94 265 478 ++U~~~
es2255 593 815 526 ++U~~~
fr2565 283
13 matches
Mail list logo
