On Fri, Mar 28, 2008 at 2:15 PM, Julian Foad <julianfoad_at_btopenworld.com> wrote:
> 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.
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).
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? 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.
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.
Paul
> 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
>
>
---------------------------------------------------------------------
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 04:20:01 CEST