On 23/02/2007 0.32, Hyrum K. Wright wrote:
> Proposed Behavior
> -----------------
> To maintain backward compatibility, all the reporting commands will
> continue to to behave as they currently do. A '--merge-sensitive' (we
> can bikeshed about the name later) command-line switch will be added to
> the client to enable the extra merge information requested.
I'm not sure why we need to preserve backward compatibility. Merge support is
new in 1.5, so I guess it is expected that more things will be done and the
output of commands will change. The mere fact that a new property is modified
*is* a change.
Honestly, I'd rather not to add another option and just add auditing behaviour
as default. I think we should think the other way: if there is a legitimate
use case for *disabling* merge auditing, we can add a --no-merge-sensitive
later (even in SVN 1.6).
> 'svn log':
> The original log message, in the current format, with the addition of a
> list of revisions that have been merged into the target. The
> '--verbose' flag would output the log information for the merged
> revisions as well.
> (Question: What is the best way to visually represent all the data
> being returned by 'svn log --merge-sensitive'?)
I know Daniel proposed the output of svnmerge.py, but I think it's better to
be more radical here. For instance, this is output of "svn log" in the 1.4.x
branch today:
------------------------------------------------------------------------
r23493 | malcolm | 2007-02-24 09:24:26 +0100 (Sat, 24 Feb 2007) | 2 lines
Changed paths:
M /branches/1.4.x/STATUS
* STATUS: Nominate r23491, r23492.
------------------------------------------------------------------------
r23474 | dlr | 2007-02-23 00:04:33 +0100 (Fri, 23 Feb 2007) | 5 lines
Changed paths:
M /branches/1.4.x
M /branches/1.4.x/STATUS
M /branches/1.4.x/subversion/bindings/swig/ruby/svn/client.rb
M /branches/1.4.x/subversion/bindings/swig/ruby/svn/wc.rb
Backport r23405 and r23406 from trunk into the 1.4.x branch, fixing
typos in Ruby bindings method name and documentation.
Approved by: +1: blair, dlr, kou
------------------------------------------------------------------------
And this is what I would like to see:
------------------------------------------------------------------------
r23493 | malcolm | 2007-02-24 09:24:26 +0100 (Sat, 24 Feb 2007) | 2 lines
Changed paths:
M /branches/1.4.x/STATUS
* STATUS: Nominate r23491, r23492.
------------------------------------------------------------------------
r23474 | dlr | 2007-02-23 00:04:33 +0100 (Fri, 23 Feb 2007) | 5 lines
Changed paths:
M /branches/1.4.x
M /branches/1.4.x/STATUS
M /branches/1.4.x/subversion/bindings/swig/ruby/svn/client.rb
M /branches/1.4.x/subversion/bindings/swig/ruby/svn/wc.rb
Backport r23405 and r23406 from trunk into the 1.4.x branch, fixing
typos in Ruby bindings method name and documentation.
Approved by: +1: blair, dlr, kou
------------------------------------------------------------------------
r23406 | blair | 2007-02-16 03:30:50 +0100 (Fri, 16 Feb 2007) | 4 lines
Changed paths:
M /trunk/subversion/bindings/swig/ruby/svn/wc.rb
* subversion/bindings/swig/ruby/svn/wc.rb:
(merge_prop_diffs):
Renamed from mrege_prop_diffs.
------------------------------------------------------------------------
r23405 | blair | 2007-02-16 03:29:38 +0100 (Fri, 16 Feb 2007) | 3 lines
Changed paths:
M /trunk/subversion/bindings/swig/ruby/svn/client.rb
* subversion/bindings/swig/ruby/svn/client.rb:
Spelling fix: s/avaiable/available/g.
------------------------------------------------------------------------
I think this example might not even be the best one, because this is a release
branch. But think of the output of svn log of SVN trunk after the
merge-tracking branch is merged. You probably don't care about anything else
*but* seeing the actual revisions that are the commits in the branch. Having
them "quoted" like svnmerge.py does doesn't help in any way. It just
highlights an implementation detail of how SVN merges work.
Notice that if you really need, you can still know that the commit was done in
another branch by looking at the modifies paths (in the --verbose output shown
above). I assume you really don't need this information most of the time, but
still it's there.
Moreover, with the example above, it would be nice if "svn diff -c23405" did
the right thing, even if you're sitting in the branch...
> 'svn blame':
> Two additional columns for each line, one with the original revision
> number, and one with the original author of that line. Unlike other
> commands, we do not need to worry about multiple source revisions,
> because each line can have at most one author.
Here too, I don't see why we need to confuse people with the two columns. I
think by default 99% of the cases people just want to know the original
revision in which the original commit is done, with the original log message
and original author. They want the auditing behaviour *by default*.
If and only if a legitimate use case for *disabling* it is found, we could
conceive a "svn blame --no-merge-sensitive" which shows the commits of the
merges themselves.
> 'svn info':
> Add two more pieces of information: 'Last Original Author:' and 'Last
> Original Revision:'. Note that these could either be set by a merge to
> the node, or a commit to the node. In the latter case, they would be
> the same as the 'Last Author' and 'Last Revision'.
I'm fine with this. It's clear and simple.
> (Question: Do we need '--merge-sensitive' to do this? Should the 'Last
No, if you ask me :) It should be the default.
> Original {Author,Revision}' lines appear if only different from 'Last
> {Author, Revision}'?)
No, that's confusing, it would seem to me as if auditing wasn't working for
some reason. I think there's nothing to gain and much to confuse.
--
Giovanni Bajo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Feb 25 11:00:43 2007