Hi, "svn mergeinfo" folks.
I can see two alternative approaches:
(1) Make an initial implementation of "svn mergeinfo" that tries to be a bare
minimum data provider.
(2) Make an initial implementation of (a merge reporting command) that tries to
provide "svn log" type of output.
If we do (1), which is what I've been pushing, I submit that will be a sound
basis on which people can build scripts, or pipe the output to "xargs svn log
-r", etc., and for us to extend later to provide more types of info about merges.
If we do (2), that will be more immediately accessible to command-line users
who wish they were using a GUI (joke - sort of :-) and just want to see
friendly, informative output with a simple command invocation.
We could even do both.
If we do (2), it bothers me that an "svn mergeinfo" command would be
effectively an "svn log" command with potentially all of "svn log"'s options
and output format, yet having a command name that implies outputting some sort
of "info" that's not necessarily a "log". We could alleviate my botheration by
calling it:
svn mergelog
and then I would be very happy for it to take any or all of "svn log"'s
options, and it would be obvious that the default output should be "what's been
merged" not "what's eligible". It could still take some non-log options such as
the "--show-sources" idea for providing a list of branches. There might still
be ways in which it wouldn't be quite semantically compatible with "svn log" -
such as not being "recursive" by default in the sense of picking up all
relevant log entries for merges that were applied to subdirectories. Such
differences might be OK though.
As for the "log -v" problem (were all the paths shown really merged here?), I
could be persuaded that this isn't a problem if the output is clearly an "svn
log" output.
Good idea: "svn mergelog"?
Now, here's today's monologue on doing (1). Skip it if you don't like it!
Paul Burba wrote:
> I guess where we differ is that you present the log -v problem as the
> tip of the iceberg of edge cases that will arise if we go ahead and
> make svn mergeinfo output log info. I'm just not seeing the potential
> for other problems (though maybe that is just a lack of imagination).
Can you recall any small part of the merge tracking development that looked
like it had no potential for unexpected problems, and that indeed turned out to
have no unexpected problems? :-)
> As for the log -v problem goes, it still exists if all we do is
> provide bare revision numbers. I think we all agree that if all a
> user gets is revision numbers, then they will find a way to feed those
> to log and then have the same problem no?
They will get the same *result* that we're talking about, but the way they
perceive the *problem* will be very different. They will say, "Ah, I asked
Subversion to show me the full log of each revision that the merge was
connected with, and that's what it's showing me. What I'd really like is to
filter this output according to what parts of each revision were actually
affecting my target branch."
If, on the other hand, the user invokes a command that is described as "show me
verbose information about what was merged", and it outputs what we described
above, they would say, "Ah, Subversion is not telling me what I asked for, it's
being totally dumb. This command is broken."
> This is one reason I
> suggested in IRC that 'svn mergeinfo --show-revs=sources TARGET' show
> the sources for TARGET *and* any of its subtrees which have their own
> explicit mergeinfo. That would make it clear that the mergeinfo on
> TARGET doesn't necessarily affect apply to it's subtrees with
> differing mergeinfo.
Now, that is definitely a useful thing to do. Just make sure that the interface
does not lead the user to assume that if "--show-sources" acts recursively then
"--show-revs=merged" is also acting recursively, if it isn't. Perhaps by
requiring the "--recursive" option to make the former act recursively, and
either supporting "--recursive" on the latter too or forbidding it and throwing
an "unsupported" error.
> In a perfect world svn mergeinfo TARGET -v would filter out affected
> paths from the log output if the affected subtree of TARGET had
> explicit mergeinfo showing these changes were not merged in. But
> can't we add this filtering in 1.6 if necessary? Or maybe just not
> support the -v option for now, and therefore not show affected paths,
> and then add it in 1.6 if/when we can filter those paths? In the end
> I'd just really like to see svn mergeinfo give something more useful
> than revision numbers.
I'd be very happy for "svn mergeinfo" to be able to output something more
"useful" than revision numbers, it's just that I think plain revision numbers
are a solid foundation for people to start building on (and scripting with),
and I don't think defining something more useful is an easy task.
For example, one proposal was to output the first line of "log" output:
svn mergeinfo --show-revs=eligible \
--from-source=$SVN_REPOS/branches/svn-mergeinfo-enhancements \
$SVN_REPOS/trunk
[...]
r30050 | hwright | 2008-03-26 02:47:33 +0000 (Wed, 26 Mar 2008)
r30051 | hwright | 2008-03-26 02:48:46 +0000 (Wed, 26 Mar 2008)
r30052 | clkao | 2008-03-26 03:20:09 +0000 (Wed, 26 Mar 2008)
r30053 | kfogel | 2008-03-26 03:26:30 +0000 (Wed, 26 Mar 2008)
r30054 | hwright | 2008-03-26 04:30:09 +0000 (Wed, 26 Mar 2008)
r30055 | hwright | 2008-03-26 04:31:03 +0000 (Wed, 26 Mar 2008)
r30056 | hwright | 2008-03-26 04:32:28 +0000 (Wed, 26 Mar 2008)
r30057 | stsp | 2008-03-26 14:53:23 +0000 (Wed, 26 Mar 2008)
r30058 | stsp | 2008-03-26 14:56:37 +0000 (Wed, 26 Mar 2008)
[...]
This is certainly more informative. But is it really "useful"? Sometimes it is,
e.g. if you know that "clkao" only made one commit to this branch near that
date and that's the one you want. But if you want one of hwright's commits? No.
By itself, this is a degree of enhancement that will help some of the people
some of the time. It needs more than this to be generally useful. It needs an
option to output the log message as well, and perhaps an option to print just
the first line or two of the log message. It needs an option to print what
paths were affected - or perhaps a brief summary of what paths were affected
like we show in the commit emails.
Obviously a GUI is a better platform for displaying such complex,
user-selectable, expandable information, but it should also be possible for the
command-line client to do a half-way reasonable job. Just like "svn log" does.
I would actually encourage somebody who wants to work on such a useful,
comprehensive interface, but it's an unbounded amount of (mostly UI design)
work, unless it is to be exactly "svn log" wrapped in a revision-filtering logic.
For something to be back-ported into v1.5 we really do need the simplest
possible solution, where "simple" doesn't mean "naive attempt to give what the
user really wants" but "concise, stable, unsurprising, easy to review for
correctness".
So, *if we do (1) "svn mergeinfo"* I'd like it to be just revision numbers. But
if we do (2) "svn mergelog" then I accept we could (probably) reach a good
design that first finds the appropriate revision numbers and then mimics "svn
log" output for each one. This would definitely be more work than (1), but not
"unbounded" in the sense of trying to design a new "svn mergeinfo" verbose output.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-04-01 16:07:40 CEST