C. Michael Pilato wrote:
> Mark Phippard wrote:
>
>> I agree with you in principle, but Dan and I have been thinking and
>> talking about this since last summer. I think if you really stop and
>> think about it, it is obvious that log output is what someone wants
>> here. In my opinion, a list of revisions is useless. What script
>> would that possibly drive? If you are just going to feed them back
>> into a merge command, then that is a fairly useless script. svn merge
>> will already do this for you automatically by just omitting the
>> revision argument. Maybe you know you only want revisions over 1000
>> for some reason. OK, again, svn merge -r1000:HEAD will do this
>> automatically.
>>
>> People are going to want to run this command so they can make informed
>> decisions about what to merge. Such as "have we nominated everything
>> for backport into 1.5 that needs to be". To answer those questions,
>> you want a filtered log. It does not make sense to have the command
>> already have all that information and just discard it when we know
>> that is what people want.
To answer that question, people want a lot of high-level information. This
command can begin to give them that information, but it can't in general give
them all the high-level information they will ever need.
(Of course the system has lots of interesting information inside it, but that
doesn't mean we should print it all out to avoid "wasting" it. I'm sure you
didn't mean for that to sound the way it sounded.)
> There is some legitimacy to just printing revisions. After all, even if
> most folks want log output, they can pipe those revisions into 'svn log'
> just as easily as anything else.
>
> That said, *all* of our output ('cept the XML flavors) is designed to be
> piped and munged and scripted and so on, yet still actually deliver some
> immediate value that doesn't require extra processing. 'svn status'
> doesn't just print paths that have to be piped into 'svn status -v'.
> 'svn log' doesn't generate just revisions that have to be piped into
> 'svn log -v'. The downside is that people do have to use 'cut' and deal
> with tabular output, sure. But to date, that doesn't seem to have
> caused any great controversy. For these reason I endorse the use of
> log-style output for this mergeinfo-reporting subcommand.
>
> The only thing I think folks will want almost as much as logs are the
> diffs of the revisions. But the performance cost of showing those diffs
> is prohibitive enough to rule out showing them automatically, and those
> same folks can just run 'svn mergeinfo -q | cut ... | showchange.pl and
> get logs and diffs together if they wish.
My point was not that we don't want to be able to show log-like output. Sure
that's useful, and we might well want to provide that.
My point was that if we define something really really simple then we stand a
fair chance of being able to implement it now in a reasonable amount of effort
with a result that's useful and a foundation for further expansion. If instead
we choose to implement the various flavours of log-like output now, then I
predict we will spend an inordinate amount of effort getting it to an
acceptable standard. For example, I mentioned that if we provide the "log -v"
output of all changed paths per source revision, we will likely find that this
is misleading to the point of being a bug when we apply it to revisions that
were only partially merged. These sort of issues (which can individually be
seen as "corner cases") quickly multiply up.
Therefore let's define something that we stand a chance of being able to
complete correctly now, and consider making it more friendly later.
- 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-03-28 19:15:33 CET