You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Paul Burba <pt...@gmail.com> on 2008/04/01 02:19:49 UTC
Re: RFC: svn mergeinfo improvements for 1.5
On Fri, Mar 28, 2008 at 2:15 PM, Julian Foad <ju...@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@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: svn mergeinfo improvements for 1.5
Posted by "C. Michael Pilato" <cm...@collab.net>.
Yay! Consensus amongst the most active parties!
I will drive these changes ASAP (realistically, tomorrow).
Julian Foad wrote:
> C. Michael Pilato wrote:
>> Paul Burba wrote:
>>
>>> Here is my (probably futile) attempt to define what the bare minimum is:
>>>
>>> A) Revisions are displayed one per line (no ranges)
>>
>> +1
>>
>>> B) Inoperative revisions are filtered out, but for merged and eligible
>>> revisions*
>>
>> +1
>>
>>> C) Support only one TARGET path/URL
>>
>> +1
>>
>>> D) Require --from-source.
>>
>> Requiring an option (like --from-source) is weird. They're supposed
>> to be OPTIONal. :-) Should we drop --from-source, and make the usage
>> syntax similar to 'svn merge' itself?
>>
>> $ svn mergeinfo SOURCE [TARGET[@PEG-REV]]
>
> +1. Having the syntax be more like "svn merge" is (a) very logical
> because that's exactly the kind of inputs we're specifying, and (b) less
> typing. (For some reason I can't articulate, a non-optional option
> didn't actually bother me much, but this is better all round.)
>
>
>>> E) Show merged revisions by default. Add a new option --show-revs
>>> ['merged' | 'eligible'] allowing eligible to be shown instead.
>>
>> +1
>>
>>> F) Make recursive by default, i.e. any subtrees of the TARGET with
>>> their own explicit mergeinfo are listed separately. This implies at
>>> least one level of indentation.
>>
>> As I expressed in IRC, this adds some trickiness. We'll have to
>> bifurcate the logic so that URL TARGETs make use of the
>> include_descendants=TRUE flag to svn_ra_get_mergeinfo(), but working
>> copy TARGETs will have to be crawled in full with either per-item
>> invocations of get_mergeinfo() (which is awfully expensive, and grows
>> in cost the deeper in the tree you get) or custom inheritance-tracking
>> logic. (This special-casing of WC TARGETs due to needing honest
>> answers in light of mixed revs, switched children, etc.)
>>
>> So, defaulting to --depth=infinity today complicates the work of
>> getting us ready for 1.5.
>
> +1 on being non-recursive (depth=empty) and not supporting the "--depth"
> option yet. We can add it in The Future.
>
>> On the flip side, adding --depth support in 1.6 means adding a level
>> of indentation (unless we go ahead and build that into 1.5), but also
>> likely means dealing with depths of dubious value (is 'svn mergeinfo
>> --depth files' likely to be terribly useful?). Maybe that's not a big
>> deal ... the same could probably be said about the depth support in
>> many of our subcommands.
>
> I don't think it matters much whether we provide any indentation now.
> The chance of it exactly matching our future 1.6 outputs is ... well,
> not 100%, at least, so it's hardly worth bothering.
>
>> (We're close ... can you taste it?)
>
> Yes, the taste of sweet simplicity. All is settled and should be ready
> very soon.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: RFC: svn mergeinfo improvements for 1.5
Posted by Julian Foad <ju...@btopenworld.com>.
C. Michael Pilato wrote:
> Paul Burba wrote:
>
>> Here is my (probably futile) attempt to define what the bare minimum is:
>>
>> A) Revisions are displayed one per line (no ranges)
>
> +1
>
>> B) Inoperative revisions are filtered out, but for merged and eligible
>> revisions*
>
> +1
>
>> C) Support only one TARGET path/URL
>
> +1
>
>> D) Require --from-source.
>
> Requiring an option (like --from-source) is weird. They're supposed to
> be OPTIONal. :-) Should we drop --from-source, and make the usage
> syntax similar to 'svn merge' itself?
>
> $ svn mergeinfo SOURCE [TARGET[@PEG-REV]]
+1. Having the syntax be more like "svn merge" is (a) very logical because
that's exactly the kind of inputs we're specifying, and (b) less typing. (For
some reason I can't articulate, a non-optional option didn't actually bother me
much, but this is better all round.)
>> E) Show merged revisions by default. Add a new option --show-revs
>> ['merged' | 'eligible'] allowing eligible to be shown instead.
>
> +1
>
>> F) Make recursive by default, i.e. any subtrees of the TARGET with
>> their own explicit mergeinfo are listed separately. This implies at
>> least one level of indentation.
>
> As I expressed in IRC, this adds some trickiness. We'll have to
> bifurcate the logic so that URL TARGETs make use of the
> include_descendants=TRUE flag to svn_ra_get_mergeinfo(), but working
> copy TARGETs will have to be crawled in full with either per-item
> invocations of get_mergeinfo() (which is awfully expensive, and grows in
> cost the deeper in the tree you get) or custom inheritance-tracking
> logic. (This special-casing of WC TARGETs due to needing honest answers
> in light of mixed revs, switched children, etc.)
>
> So, defaulting to --depth=infinity today complicates the work of getting
> us ready for 1.5.
+1 on being non-recursive (depth=empty) and not supporting the "--depth" option
yet. We can add it in The Future.
> On the flip side, adding --depth support in 1.6 means adding a level of
> indentation (unless we go ahead and build that into 1.5), but also
> likely means dealing with depths of dubious value (is 'svn mergeinfo
> --depth files' likely to be terribly useful?). Maybe that's not a big
> deal ... the same could probably be said about the depth support in many
> of our subcommands.
I don't think it matters much whether we provide any indentation now. The
chance of it exactly matching our future 1.6 outputs is ... well, not 100%, at
least, so it's hardly worth bothering.
> (We're close ... can you taste it?)
Yes, the taste of sweet simplicity. All is settled and should be ready very soon.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: svn mergeinfo improvements for 1.5
Posted by "C. Michael Pilato" <cm...@collab.net>.
Paul Burba wrote:
> Here is my (probably futile) attempt to define what the bare minimum is:
>
> A) Revisions are displayed one per line (no ranges)
+1
> B) Inoperative revisions are filtered out, but for merged and eligible
> revisions*
+1
> C) Support only one TARGET path/URL
+1
> D) Require --from-source.
Requiring an option (like --from-source) is weird. They're supposed to be
OPTIONal. :-) Should we drop --from-source, and make the usage syntax
similar to 'svn merge' itself?
$ svn mergeinfo SOURCE [TARGET[@PEG-REV]]
> E) Show merged revisions by default. Add a new option --show-revs
> ['merged' | 'eligible'] allowing eligible to be shown instead.
+1
> F) Make recursive by default, i.e. any subtrees of the TARGET with
> their own explicit mergeinfo are listed separately. This implies at
> least one level of indentation.
As I expressed in IRC, this adds some trickiness. We'll have to bifurcate
the logic so that URL TARGETs make use of the include_descendants=TRUE flag
to svn_ra_get_mergeinfo(), but working copy TARGETs will have to be crawled
in full with either per-item invocations of get_mergeinfo() (which is
awfully expensive, and grows in cost the deeper in the tree you get) or
custom inheritance-tracking logic. (This special-casing of WC TARGETs due
to needing honest answers in light of mixed revs, switched children, etc.)
So, defaulting to --depth=infinity today complicates the work of getting us
ready for 1.5.
On the flip side, adding --depth support in 1.6 means adding a level of
indentation (unless we go ahead and build that into 1.5), but also likely
means dealing with depths of dubious value (is 'svn mergeinfo --depth files'
likely to be terribly useful?). Maybe that's not a big deal ... the same
could probably be said about the depth support in many of our subcommands.
(We're close ... can you taste it?)
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: RFC: svn mergeinfo improvements for 1.5
Posted by Paul Burba <pt...@gmail.com>.
On Tue, Apr 1, 2008 at 11:03 AM, Mark Phippard <ma...@gmail.com> wrote:
> On Tue, Apr 1, 2008 at 10:07 AM, Julian Foad <ju...@btopenworld.com> wrote:
> > 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.
>
> While some of your other ideas seem pretty good, I think at this point
> we are probably best off sticking with this sort of idea. Let's just
> take the simple approach. That is basically how the command currently
> works, and this is really just about making the output more accessible
> rather than extending or changing the output at this point.
>
> The key is that the existing API is solid and usable for GUI's. We
> should probably keep the CLI simple until we are sure about what we
> want to implement.
+1 to going to simple route and just displaying the bare minimum and
then working on a more elaborate CLI in 1.6.
Here is my (probably futile) attempt to define what the bare minimum is:
A) Revisions are displayed one per line (no ranges)
B) Inoperative revisions are filtered out, but for merged and eligible
revisions*
C) Support only one TARGET path/URL
D) Require --from-source.
E) Show merged revisions by default. Add a new option --show-revs
['merged' | 'eligible'] allowing eligible to be shown instead.
F) Make recursive by default, i.e. any subtrees of the TARGET with
their own explicit mergeinfo are listed separately. This implies at
least one level of indentation.
*I believe Mike has already done some of the heavy lifting for the
filtering on the svn-mergeinfo-enhancements branch, so we are probably
not that far off.
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: svn mergeinfo improvements for 1.5
Posted by Mark Phippard <ma...@gmail.com>.
On Tue, Apr 1, 2008 at 10:07 AM, Julian Foad <ju...@btopenworld.com> wrote:
> 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.
While some of your other ideas seem pretty good, I think at this point
we are probably best off sticking with this sort of idea. Let's just
take the simple approach. That is basically how the command currently
works, and this is really just about making the output more accessible
rather than extending or changing the output at this point.
The key is that the existing API is solid and usable for GUI's. We
should probably keep the CLI simple until we are sure about what we
want to implement.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: svn mergeinfo improvements for 1.5
Posted by Julian Foad <ju...@btopenworld.com>.
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@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org