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/03/18 20:49:57 UTC
RFC: svn mergeinfo improvements for 1.5
Today the svn mergeinfo command gives basic information on what
revisions have been merged to a path and what revisions are eligible
to be merged to that path, e.g.:
>svn mergeinfo merge_tests-90\A_COPY
Path: merge_tests-90\A_COPY
Source path: /A
Merged ranges: r1:6
Eligible ranges: r6:7
This meets our basic requirement for change set availability auditing,
see http://svn.collab.net/repos/svn/trunk/www/merge-tracking/requirements.html#change-set-availability
There are some problems though:
1) The eligible ranges can include revisions that don't apply to the
merge source, see
http://subversion.tigris.org/issues/show_bug.cgi?id=3126
2) You can specify multiple targets but only one --from-source, is
this ever going to be useful? Is the support of multiple targets even
that useful? It adds another level of indentation to the output,
which is already a bit ugly to start with (see 3).
3) When there are a *lot* of merged/eligible ranges then the output is
not easily parsed. Look at a 1.5.x WC for example:
>svn mergeinfo \svn\src-branch
Path: \SVN\src-branch
Source path: /trunk
Merged ranges: r0:29080, r29084:29089, r29090:29091, r29093:29107,
r29110:29111, r29113:29114, r29116:29117, r29125:29127, r29128:29133,
r29134:29150,
r29152:29164, r29165:29166, r29173:29174, r29175:29186, r29187:29189,
r29192:29194, r29197:29200, r29201:29206, r29207:29251, r29253:29256,
r29260:29261, r
29266:29273, r29276:29277, r29279:29281, r29283:29284, r29286:29303,
r29304:29307, r29308:29325, r29326:29343, r29344:29348, r29357:29379,
r29380:29392, r2
9396:29397, r29398:29399, r29400:29401, r29408:29409, r29411:29412,
r29413:29415, r29416:29423, r29424:29426, r29428:29429, r29432:29434,
r29435:29438, r29
439:29447, r29448:29466, r29467:29478, r29481:29482, r29483:29484,
r29485:29487, r29488:29489, r29490:29491, r29492:29493, r29495:29496,
r29497:29498, r295
07:29508, r29526:29528, r29530:29531, r29532:29533, r29538:29540,
r29541:29542, r29543:29544, r29545:29546, r29550:29551, r29552:29553,
r29555:29556, r2955
8:29559, r29564:29565, r29566:29569, r29570:29578, r29580:29581,
r29582:29583, r29590:29591, r29593:29594, r29599:29600, r29602:29603,
r29606:29607, r29610
:29611, r29612:29614, r29618:29619, r29622:29623, r29624:29626,
r29629:29631, r29633:29634, r29641:29642, r29647:29648, r29649:29650,
r29655:29656, r29658:
29660, r29662:29664, r29670:29672, r29676:29680, r29691:29692,
r29737:29739, r29741:29744, r29745:29746, r29750:29751, r29762:29763,
r29768:29770, r29783:2
9784, r29786:29787, r29820:29821, r29823:29824, r29827:29828,
r29834:29835, r29854:29855, r29867:29869, r29877:29878, r29882:29884
Eligible ranges: r29080:29084, r29089:29090, r29091:29093,
r29107:29110, r29111:29113, r29114:29116, r29117:29125, r29127:29128,
r29133:29134, r29150:2
9152, r29164:29165, r29166:29173, r29174:29175, r29186:29187,
r29189:29192, r29194:29197, r29200:29201, r29206:29207, r29251:29253,
r29256:29260, r29261:29
266, r29273:29276, r29277:29279, r29281:29283, r29284:29286,
r29303:29304, r29307:29308, r29325:29326, r29343:29344, r29348:29357,
r29379:29380, r29392:293
96, r29397:29398, r29399:29400, r29401:29408, r29409:29411,
r29412:29413, r29415:29416, r29423:29424, r29426:29428, r29429:29432,
r29434:29435, r29438:2943
9, r29447:29448, r29466:29467, r29478:29481, r29482:29483,
r29484:29485, r29487:29488, r29489:29490, r29491:29492, r29493:29495,
r29496:29497, r29498:29507
, r29508:29526, r29528:29530, r29531:29532, r29533:29538,
r29540:29541, r29542:29543, r29544:29545, r29546:29550, r29551:29552,
r29553:29555, r29556:29558,
r29559:29564, r29565:29566, r29569:29570, r29578:29580, r29581:29582,
r29583:29590, r29591:29593, r29594:29599, r29600:29602, r29603:29606,
r29607:29610,
r29611:29612, r29614:29618, r29619:29622, r29623:29624, r29626:29629,
r29631:29633, r29634:29641, r29642:29647, r29648:29649, r29650:29655,
r29656:29658, r
29660:29662, r29664:29670, r29672:29676, r29680:29691, r29692:29737,
r29739:29741, r29744:29745, r29746:29750, r29751:29762, r29763:29768,
r29770:29783, r2
9784:29786, r29787:29820, r29821:29823, r29824:29827, r29828:29834,
r29835:29854, r29855:29867, r29869:29877, r29878:29882, r29884:29943
Ouch! For the merged ranges this is little better than doing a propget:
>svn pg svn:mergeinfo \svn\src-branch
/trunk:1-29080,29085-29089,29091,29094-29107,29111,29114,29117,29126-29127,29129-29133,29135-29150,29153-29164,29166,29174,29176-29186,29188-29189,29193-29
194,29198-29200,29202-29206,29208-29251,29254-29256,29261,29267-29273,29277,29280-29281,29284,29287-29303,29305-29307,29309-29325,29327-29343,29345-29348,2
9358-29379,29381-29392,29397,29399,29401,29409,29412,29414-29415,29417-29423,29425-29426,29429,29433-29434,29436-29438,29440-29447,29449-29466,29468-29478,
29482,29484,29486-29487,29489,29491,29493,29496,29498,29508,29527-29528,29531,29533,29539-29540,29542,29544,29546,29551,29553,29556,29559,29565,29567-29569
,29571-29578,29581,29583,29591,29594,29600,29603,29607,29611,29613-29614,29619,29623,29625-29626,29630-29631,29634,29642,29648,29650,29656,29659-29660,2966
3-29664,29671-29672,29677-29680,29692,29738-29739,29742-29744,29746,29751,29763,29769-29770,29784,29787,29821,29824,29828,29835,29855,29868-29869,29878,298
~~~~~
Anyway, Mike, Julian, and I were discussing these problems today and
came to a consensus that the following changes would be nice to get
into 1.5:
A) When displaying eligible revisions display only those that affect
the merge source (i.e. don't display revisions, which if merged, would
be no-ops).
B) Support only one target, still support --from-source filter.
C) By default show only merged revisions. Add a new option
--merged-revs ARG ('merged', 'eligible'). Yes, as things stand now,
it would make more sense to just use an option like '--show-eligible',
but we want to be ready for the day when true revision blocking is
available so we can easily see --merged-revs=blocked.
D) Print the revision lists as one range per line, e.g.:
>svn mergeinfo \svn\src-branch --merged-revs eligible
Source path: /trunk
Eligible ranges:
r29080:29084
r29089:29090
r29091:29093
r29107:29110
.
<snip>
.
r29869:29877
r29878:29882
r29884:29943
These changes make svn mergeinfo a bit more useful today, while
allowing subsequent changes in 1.6 to be made based on user feedback
(e.g. --verbose could show log info for merged/eligible revisions).
Any objections to these changes and/or the goal of getting them into
1.5? Alternate suggestions?
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 David Glasser <gl...@davidglasser.net>.
On Tue, Mar 18, 2008 at 1:49 PM, Paul Burba <pt...@gmail.com> wrote:
> 2) You can specify multiple targets but only one --from-source, is
> this ever going to be useful? Is the support of multiple targets even
> that useful? It adds another level of indentation to the output,
> which is already a bit ugly to start with (see 3).
I don't care about being able to *specify* multiple targets, but
probably we should keep the output format like it is now, so we can
add a '-R' flag which runs
svn_ra_get_mergeinfo(include_descendants=TRUE)...
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
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 Paul Burba <pt...@gmail.com>.
On Tue, Mar 25, 2008 at 11:59 AM, Karl Fogel <kf...@red-bean.com> wrote:
> "Paul Burba" <pt...@gmail.com> writes:
> > Ok, taking into account what has been said so far (including some
> > off-dev conversations between Mike, Julian, and myself), how does the
> > revised proposal sound?
> >
> > A) When displaying eligible *or* merged revisions, display only those
> > that affect the merge source (i.e. don't display revisions, which
> > if/when merged, would be/were no-ops). There has been some discussion
> > that displaying the no-op merges might also be useful on occasion, but
> > I still feel that filtering the no-ops is more useful, more of the
> > time. If, after 1.5 releases, people are clamoring for the no-ops, we
> > could add a --show-no-ops option. Heck, we could do this now if
> > people really think there is a need.
> >
> > B) Support only one target, still support --from-source filter.
> >
> > C) By default show only eligible revisions. Add a new option
> > --show-revs ARG ('merged', 'eligible'). After more thought I like
> > 'eligible' as the default better, since the merged revisions are
> > already represented in the svn:mergeinfo prop.
>
> Yay on (A), (B), and (C). See below about (D) :-).
>
> Regarding (C): suggest '--merged' and '--eligible' as the flag names, or
> '--show-merged' and '--show-eligible'. Kind of green.bikeshed.com, I
> know; maybe it doesn't make much difference. Agree about the default.
I was suggesting --show-revs ARG (eligible | merged) for two reasons.
First, because we might have "true blocking" one of these days and
adding 'blocked' as a valid arg seemed better than later adding yet
another option, --show-blocked. The second reason is that I don't
want to show both merged and eligible revisions in one pass since that
makes the log indentation problem that much worse.
> > D) Print the revision lists as one range per line (if -v is not
> > specified). This keeps things easy to read/parse, while attempting to
> > avoid the excessive vertical output one rev per range more or less
> > guarantees. Before you say no read E...
>
> So what happened to Mike's proposal of one rev per line?
>
> In practice, people are going to be piping through a pager or
> redirecting to a file, no matter what. Even with range compression,
> these lists only get bigger.
>
> So let's just think about it from a use case point of view. What are
> people trying to do? They're probably trying to figure out if a given
> revision has been merged and/or is eligible to be merged. The most
> useful thing would be if they could search the output *for that exact
> revision*.
Ok, you've sold me with that last point. +1 to one revision per line
(or is that one line per revision?)
> Also, if you do one rev per line, then filtering out no-op revisions
> really is guaranteed to shorten the output. Where as with ranges, then
> filtering out no-op revisions can increase the number of ranges, as Mike
> pointed out. Although the number of ranges will never be more than the
> number of revisions, of course, there is an inherent inconvenience in
> dealing with larger numbers of ranges -- if you're searching by eye to
> figure out what happened to a particular revision, that is.
>
> > E) Add support for the --verbose/-v and --quiet/-q flags. If
> > specified, this produces output exactly as if doing svn log -q/-v for
> > each of the eligible/merged revisions. If the --from-source option is
> > specified then we don't need to indent, but if not we'll need to
> > indent the log output per source. The latter is going to be a bit
> > ugly, but I see no way of avoiding it.
> >
> > Thoughts?
>
> It sounds like (E) means that adding the -q flag to 'mergeinfo' would
> actually cause it to give *more* output, since behaving like 'log -q'
> means giving more information than just a revision number.
>
> That's going to be confusing.
Hmm, yeah, that is a bit confusing. I just wanted a way to make the
"log" output of svn mergeinfo analogous to svn log's, i.e.:
svn log -q ---> Rev/Author/Date
svn log ---> Rev/Author/Date and Log Message
svn log -q -v ---> Rev/Author/Date and Changed Paths
svn log -v ---> Rev/Author/Date, Log Message, and Changed Paths
> Instead, how about a --show-log flag or
> something, if people want the log messages on the spot? (And then -q/-v
> can be meaningful when --show-log is given. They don't have to be
> meaningful without --show-log; or we can just save them to mean
> something by themselves in the future.)
IIUYC, you suggesting this:
svn mergeinfo --show-log -q --> svn log -q
svn mergeinfo --show-log --> svn log
svn mergeinfo --show-log -q -v --> svn log -q -v
svn mergeinfo --show-log -v --> svn log -v
svn mergeinfo -v --> No log info
svn mergeinfo -q --> No log info
If that is what you are saying then +1.
Paul
> -Karl
>
---------------------------------------------------------------------
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>.
Mark Phippard wrote:
> On Thu, Mar 27, 2008 at 4:24 PM, Paul Burba <pt...@gmail.com> wrote:
>> On Thu, Mar 27, 2008 at 3:36 PM, C. Michael Pilato <cm...@collab.net> wrote:
>> > C. We still support --from-source. But we apparently have decided to
>> > support *not* providing a source, we still has us trying to deal with
>> > multiple sets of output at once (dividers, indentation, etc.). That reduces
>> > the scriptability of the output's one-rev-per-lineness, because now wrappers
>> > have to pay attention to these section dividers and maintain state. :-(
>>
>> If scriptibility is that important, than how about this (possibly
>> quite crazy) idea:
>>
>> i) If you don't provide a --from-source but there is only *one* from
>> source then svn mergeinfo works. This saves users from typing
>> --from-source all the time, for the 1.5.x branch for example.
>>
>> ii) If you don't provide a --from-source but there are *multiple*
>> sources, then return an error saying there are multiple sources and
>> one must be specified (and suggesting iii).
>>
>> iii) Add --show-sources option which lists all the merge sources (one
>> source per line of course, allowing scripts to run this first then run
>> svn mergeinfo --from-source on each result).
>
> These are pretty good ideas. I was thinking something similar but
> could not get to the point of a suggestion. While I tend to think a
> user will only need to see one output, the one part I was concerned
> about was how can they see a list of what they can look at.
>
> Maybe a bikeshed, but could we possibly do --show-revs=sources ?
I actually kinda like this idea. It was already a concern of some that if
you made a branch but didn't merge to it, it never showed any hints about
places you might want to merge from. Maybe this is a chance to resolve
that, too, but simply calling the suggest_merge_sources() API (which returns
a superset of the mergeinfo paths) and displaying those paths as options.
Given that, a script could iterate over the output of 'svn mergeinfo
--show-revs=sources' and call 'svn mergeinfo --show-revs=eligible
--from-source=SOURCE' and so on.
--
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 Thu, Mar 27, 2008 at 4:29 PM, Mark Phippard <ma...@gmail.com> wrote:
> On Thu, Mar 27, 2008 at 4:24 PM, Paul Burba <pt...@gmail.com> wrote:
> > On Thu, Mar 27, 2008 at 3:36 PM, C. Michael Pilato <cm...@collab.net> wrote:
>
> > > C. We still support --from-source. But we apparently have decided to
> > > support *not* providing a source, we still has us trying to deal with
> > > multiple sets of output at once (dividers, indentation, etc.). That reduces
> > > the scriptability of the output's one-rev-per-lineness, because now wrappers
> > > have to pay attention to these section dividers and maintain state. :-(
> >
> > If scriptibility is that important, than how about this (possibly
> > quite crazy) idea:
> >
> > i) If you don't provide a --from-source but there is only *one* from
> > source then svn mergeinfo works. This saves users from typing
> > --from-source all the time, for the 1.5.x branch for example.
> >
> > ii) If you don't provide a --from-source but there are *multiple*
> > sources, then return an error saying there are multiple sources and
> > one must be specified (and suggesting iii).
> >
> > iii) Add --show-sources option which lists all the merge sources (one
> > source per line of course, allowing scripts to run this first then run
> > svn mergeinfo --from-source on each result).
>
> These are pretty good ideas. I was thinking something similar but
> could not get to the point of a suggestion. While I tend to think a
> user will only need to see one output, the one part I was concerned
> about was how can they see a list of what they can look at.
>
> Maybe a bikeshed, but could we possibly do --show-revs=sources ?
That sounds ok, except that maybe the option should simply be --show
[eligible | merged | sources], or maybe --show-info, something besides
--show-revs, since show-revs=sources isn't going to list revisions at
all.
> > > D. We've discussed not showing both eligible and merged [and blocked] at the
> > > same time, but using a switch to say which flavor of output we want. That's
> > > cool, because it reduces our indentation/output-sets count again. But I
> > > disagree with the idea of making "eligible" the default while still
> > > maintaining the subcommand name "mergeinfo" which to me -- admittedly
> > > tainted by knowledge of the internals -- means the command will show you
> > > information about merges, not about would-be merges that may never come to
> > > be. Besides, the claim that "you don't need 'svn mergeinfo' to show actual
> > > merges by default because 'svn pget svn:mergeinfo'" is only true when you
> > > happen to execute 'svn mergeinfo' on the root of a branch which said
> > > svn:mergeinfo property is likely to reside.
> >
> > I'm still partial to showing eligible by default, but only because
> > that is what I'd tend to use it for. But I don't feel that strongly
> > about it either way. I mean honestly, does *anyone* feel that
> > strongly about what the default it? How about whoever codes it gets
> > to choose? ;-)
>
> Personally, I would be OK with --show-revs being mandatory. But I
> think showing the merged information makes some sense just because of
> the command name. dlr and I went through all of this back when we
> were discussing a command name. These sorts of questions essentially
> paralyzed us.
In the interest of reducing paralysis I hereby do a 180 and say +1 for
merged revisions as the default.
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 Thu, Mar 27, 2008 at 4:24 PM, Paul Burba <pt...@gmail.com> wrote:
> On Thu, Mar 27, 2008 at 3:36 PM, C. Michael Pilato <cm...@collab.net> wrote:
> > C. We still support --from-source. But we apparently have decided to
> > support *not* providing a source, we still has us trying to deal with
> > multiple sets of output at once (dividers, indentation, etc.). That reduces
> > the scriptability of the output's one-rev-per-lineness, because now wrappers
> > have to pay attention to these section dividers and maintain state. :-(
>
> If scriptibility is that important, than how about this (possibly
> quite crazy) idea:
>
> i) If you don't provide a --from-source but there is only *one* from
> source then svn mergeinfo works. This saves users from typing
> --from-source all the time, for the 1.5.x branch for example.
>
> ii) If you don't provide a --from-source but there are *multiple*
> sources, then return an error saying there are multiple sources and
> one must be specified (and suggesting iii).
>
> iii) Add --show-sources option which lists all the merge sources (one
> source per line of course, allowing scripts to run this first then run
> svn mergeinfo --from-source on each result).
These are pretty good ideas. I was thinking something similar but
could not get to the point of a suggestion. While I tend to think a
user will only need to see one output, the one part I was concerned
about was how can they see a list of what they can look at.
Maybe a bikeshed, but could we possibly do --show-revs=sources ?
> > D. We've discussed not showing both eligible and merged [and blocked] at the
> > same time, but using a switch to say which flavor of output we want. That's
> > cool, because it reduces our indentation/output-sets count again. But I
> > disagree with the idea of making "eligible" the default while still
> > maintaining the subcommand name "mergeinfo" which to me -- admittedly
> > tainted by knowledge of the internals -- means the command will show you
> > information about merges, not about would-be merges that may never come to
> > be. Besides, the claim that "you don't need 'svn mergeinfo' to show actual
> > merges by default because 'svn pget svn:mergeinfo'" is only true when you
> > happen to execute 'svn mergeinfo' on the root of a branch which said
> > svn:mergeinfo property is likely to reside.
>
> I'm still partial to showing eligible by default, but only because
> that is what I'd tend to use it for. But I don't feel that strongly
> about it either way. I mean honestly, does *anyone* feel that
> strongly about what the default it? How about whoever codes it gets
> to choose? ;-)
Personally, I would be OK with --show-revs being mandatory. But I
think showing the merged information makes some sense just because of
the command name. dlr and I went through all of this back when we
were discussing a command name. These sorts of questions essentially
paralyzed us.
--
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 "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
Re: RFC: svn mergeinfo improvements for 1.5
Posted by Paul Burba <pt...@gmail.com>.
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 Karl Fogel <kf...@red-bean.com>.
Julian Foad <ju...@btopenworld.com> writes:
> 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.
Like a bare revision number per line?
(Hint, hint... :-) )
-Karl
---------------------------------------------------------------------
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>.
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@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>.
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.
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.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
---------------------------------------------------------------------
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 Thu, Mar 27, 2008 at 6:11 PM, Julian Foad <ju...@btopenworld.com> wrote:
> Another long monologue from me.
>
> Here is my recommendation, which basically aims to make this a safe and stable
> starting point for a feature which can later become more friendly but does not
> aim to be particularly friendly in the initial implementation. In fact the
> command-line invocation is intentionally a little verbose.
>
>
> SYNTAX AND EXAMPLE
>
> svn mergeinfo --show-revs=REVTYPE --from-source=SOURCE TARGET
>
> REVTYPE is "merged" or "eligible"
> SOURCE is URL[@PEGREV] or WC-PATH
> TARGET is URL[@PEGREV] or WC-PATH
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.
I agree with the no defaults approach. We can always add some later.
I am not sure defaults make sense for this command anyway.
--
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>.
Mark Phippard wrote:
> On Thu, Mar 27, 2008 at 3:36 PM, C. Michael Pilato <cm...@collab.net> wrote:
>
>> Okay, let me try to flush my brainstate on this issue.
>>
>> A. Only accept a single TARGET. Everybody seems cool with this. This
>> reduces indentation by one level compared to where we are today. Yay!
>>
>> B. Always show log-style output, honoring both the -q and -v flags as they
>> apply to 'svn log'. This gives us one revision per line (plus some other
>> revision metadata) in -q case, and really useful full data in the -v case,
>> plus that in-between gunk in the -qv case. This forces the output into the
>> realm of needing section dividers, unless we support indentation of the log
>> output. I like this.
>>
>> C. We still support --from-source. But we apparently have decided to
>> support *not* providing a source, we still has us trying to deal with
>> multiple sets of output at once (dividers, indentation, etc.). That reduces
>> the scriptability of the output's one-rev-per-lineness, because now wrappers
>> have to pay attention to these section dividers and maintain state. :-(
>>
>> D. We've discussed not showing both eligible and merged [and blocked] at the
>> same time, but using a switch to say which flavor of output we want. That's
>> cool, because it reduces our indentation/output-sets count again. But I
>> disagree with the idea of making "eligible" the default while still
>> maintaining the subcommand name "mergeinfo" which to me -- admittedly
>> tainted by knowledge of the internals -- means the command will show you
>> information about merges, not about would-be merges that may never come to
>> be. Besides, the claim that "you don't need 'svn mergeinfo' to show actual
>> merges by default because 'svn pget svn:mergeinfo'" is only true when you
>> happen to execute 'svn mergeinfo' on the root of a branch which said
>> svn:mergeinfo property is likely to reside.
>
> I would be fine with any default, or even just requiring the
> --show-revs option always.
Another long monologue from me.
Here is my recommendation, which basically aims to make this a safe and stable
starting point for a feature which can later become more friendly but does not
aim to be particularly friendly in the initial implementation. In fact the
command-line invocation is intentionally a little verbose.
SYNTAX AND EXAMPLE
svn mergeinfo --show-revs=REVTYPE --from-source=SOURCE TARGET
REVTYPE is "merged" or "eligible"
SOURCE is URL[@PEGREV] or WC-PATH
TARGET is URL[@PEGREV] or WC-PATH
$ # Example:
$ svn mergeinfo --show-revs=merged \
--from-source=$REPOS/branches/1.5.x/ trunk-wc/
27
81
243
61565
61566
61567
61568
61569
61570
131072
$ # End of example.
OPTIONS AND OUTPUT FORMAT = no options and trivial format
Some of you know my view. KISS. Only support one target, one revision number
per line, one source, one type of revisions at a time, and no fancy
pretty-printed output. Just print a number per line, no headers, no
indentation, no nothing. And NO DEFAULTS until we're sure they're the right
defaults!
If the user wants to see the log entry for each revision, they can pipe the
output (list of revisions) to "xargs svn log PATH [-q] [-v] [--xml] -r". Even
Windows users can do that sort of thing in a script these days.
If the user wants multiple targets, they can issue multiple commands. If they
want multiple sources, ditto. If they want "all" sources, that's an extension
we can add in v1.6 by turning the "--from-source" command-line "FLAG" into a
command-line "OPTION" (becoming truly optional), as well as implementing any of
these other extensions we're talking about that may become highly desired then
but are of uncertain value now.
If we do these extensions in v1.6, they can have extended output formats
(indentation, dividers, etc.) - and the plain output can remain (compatible
with v1.5) when no such extensions are requested.
If we try to agree on a verbose output now with lots of options and dividers
and indentation, well, we just won't be happy with it in time for v1.5.
Why print individual revisions rather than ranges? There are scenarios where
ranges would be nicer, but those scenarios tend to be the single-developer,
small-scale repository, where everything is simple anyway and the developer
probably doesn't really need the feature. (Eligible revisions are contiguous
numbers because nobody is working on any other branch at all.) When the
repository is big and active, the ranges are usually broken up into single
revisions anyway by commits on other branches/projects, and scriptability of
output becomes more important, and one rev per line makes much more sense.
COMMAND NAME = "svn mergeinfo"
(Skip this section if you're already happy with the name.)
As a command for "show me what changes have/haven't been merged from A to B",
the name "svn mergeinfo" is not ideal. It's a bit vague. There is lots of other
"merge information" that Subversion could potentially show the user besides
these lists. It's named directly after the property that Subversion uses to
store its v1.5 merge info, and there is already talk of augmenting this
property with other properties in future to implement blocking, for example.
Options are: (1) call it "svn mergeinfo"; (2) invent a new name or set of names
or options to existing commands; (3) ditch the command for now and supply it as
an external script instead.
(1) is not too bad or hard to get used to; (2) would take too long now; and I'd
be happy with (3). Supplying an external script would leave us free to choose a
better command name (such as "svn log --mergeable-from=URL" or "svn merge
--dry-run --show-revisions-only" or something) when we know what the common
uses for it are. But, if we really want to, we could always upgrade to a new
and better command-line UI and just keep the old "svn mergeinfo" as a
deprecated command.
We've come far enough down the road of supplying this functionality via the
"svn mergeinfo" command that I strongly suggest we keep that name now, even if
it is not ideal. (We might even want to expand it with more options for
outputting different sorts of merge information, which would perhaps better
justify its name.)
CORRECTNESS AND COMPLETENESS = what does it really mean?
In the above sections I was stating my recommendation. Now I'm asking a question.
Can we say what this command should mean with regard to partial merges - ones
that were applied to a sub-tree?
Let's start with "revisions that have been merged from SOURCE into TARGET". By
SOURCE, we mean the line of history that ends at SOURCE[@PEGREV] and extends
back in time as far as it goes across copies, including sub-trees that were
copied separately. And we're going to list the revision number of each change
that modified SOURCE and is recorded as having been wholly or partially merged
into TARGET (into any part of TARGET's history, in the same way that we
consider SOURCE's history). We're not going to try to identify if a change was
only partially merged in, though, we're just going to mention the change as a
whole revision.
Is that what we mean?
The answer is probably, "We mean what the <so-and-so> API means." That's fine,
as long as it's documented.
When we ask it to list "revisions that are eligible to be merged from SOURCE
into TARGET", what do we mean then?
(a) Every revision that changed SOURCE and has never been applied to TARGET
in any way. (This is the complement of the "merged revisions".)
(b) Every revision that changed SOURCE and at least some part of the change
to SOURCE has never been applied to TARGET.
In either case, we're not going to try to identify if a change was only
partially merged in, we're just going to mention the change as a whole revision.
This time, the answer is probably, "We mean what the 'svn merge' command would
try to do." I guess that would be (b). Again, that's a fine answer as long as
it's documented.
Note that if we were to start to output full "svn log" information, including
the lists of paths affected, then we would likely run into difficulties with it
being entirely misleading to claim that a particular list of paths are affected
by a change, when in fact only some of those paths are affected in the target
branch. All the more reason to keep the output simple.
I hope this means we can quickly put in place something that is useful,
unambiguous, and simple enough to build on later without backward compatibility
hassles.
- Julian
>> If our goal is something that is machine parseable, then the easiest thing
>> for scripts to parse would be:
>> single-target, single-source, single-flavor, one-rev-per-line
>>
>> Anything more adds complications, some more easy to deal with than others.
>> So what can we add that brings value to the user without crossing the line
>> of machine parseability.
>>
>> Moving to log output, we have:
>> single-target, single-source, single-flavor, one-block-of-lines-per-rev
>>
>> That's not so bad. But it still leaves us unable to ask, "What merges have
>> been performed to TARGET from any sources?" The minute we allow multiple
>> sources, the machine parseability takes a hit, and we're doing indentation
>> and section headers.
>
>
> I am still not sure that use case is real. It sounds good, and like
> something you would need, but then when I think of the output it just
> never seems useful to me.
>
>
>> Since most (if not all) of the problems noted in this thread are UI related,
>> not API related...:
>>
>> 1. Should we ditch the 'svn mergeinfo' command and roll this behavior
>> into 'svn log', where we don't have to deal with
>> questions of default behaviors because those are already defined?
>
>
> Somewhere dlr has to be chuckling. We went through all of these
> gyrations last summer if you want to check dev@. It was a lot harder
> to get people to comment back then. Using svn log never felt right
> and you would have to add a lot of new options to the command.
>
>
>> 2. Should we ditch the 'svn mergeinfo' command for 1.5, and just ship
>> the APIs so that TortoiseSVN, Subclipse, and other not-constrained-
>> to-text-output consumers can still do their thing?
>>
>> 2b. Should we provide a bindings script that implements this behavior
>> so 1.5 adopters can get the info, but such that we aren't stuck
>> maintaining the chosen UI?
>>
>> Quite honestly, option 2b is looking pretty great to me right now.
>
>
> As long as the API exists I do not care. Having seen this information
> in a GUI I know that it is useful and it would be nice if the CLI
> could do it. I think we could reach consensus around svn mergeinfo
> and be done with it.
---------------------------------------------------------------------
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 Thu, Mar 27, 2008 at 3:36 PM, C. Michael Pilato <cm...@collab.net> wrote:
> Okay, let me try to flush my brainstate on this issue.
>
> A. Only accept a single TARGET. Everybody seems cool with this. This
> reduces indentation by one level compared to where we are today. Yay!
>
> B. Always show log-style output, honoring both the -q and -v flags as they
> apply to 'svn log'. This gives us one revision per line (plus some other
> revision metadata) in -q case, and really useful full data in the -v case,
> plus that in-between gunk in the -qv case. This forces the output into the
> realm of needing section dividers, unless we support indentation of the log
> output. I like this.
>
> C. We still support --from-source. But we apparently have decided to
> support *not* providing a source, we still has us trying to deal with
> multiple sets of output at once (dividers, indentation, etc.). That reduces
> the scriptability of the output's one-rev-per-lineness, because now wrappers
> have to pay attention to these section dividers and maintain state. :-(
>
> D. We've discussed not showing both eligible and merged [and blocked] at the
> same time, but using a switch to say which flavor of output we want. That's
> cool, because it reduces our indentation/output-sets count again. But I
> disagree with the idea of making "eligible" the default while still
> maintaining the subcommand name "mergeinfo" which to me -- admittedly
> tainted by knowledge of the internals -- means the command will show you
> information about merges, not about would-be merges that may never come to
> be. Besides, the claim that "you don't need 'svn mergeinfo' to show actual
> merges by default because 'svn pget svn:mergeinfo'" is only true when you
> happen to execute 'svn mergeinfo' on the root of a branch which said
> svn:mergeinfo property is likely to reside.
I would be fine with any default, or even just requiring the
--show-revs option always.
> If our goal is something that is machine parseable, then the easiest thing
> for scripts to parse would be:
> single-target, single-source, single-flavor, one-rev-per-line
>
> Anything more adds complications, some more easy to deal with than others.
> So what can we add that brings value to the user without crossing the line
> of machine parseability.
>
> Moving to log output, we have:
> single-target, single-source, single-flavor, one-block-of-lines-per-rev
>
> That's not so bad. But it still leaves us unable to ask, "What merges have
> been performed to TARGET from any sources?" The minute we allow multiple
> sources, the machine parseability takes a hit, and we're doing indentation
> and section headers.
I am still not sure that use case is real. It sounds good, and like
something you would need, but then when I think of the output it just
never seems useful to me.
> Since most (if not all) of the problems noted in this thread are UI related,
> not API related...:
>
> 1. Should we ditch the 'svn mergeinfo' command and roll this behavior
> into 'svn log', where we don't have to deal with
> questions of default behaviors because those are already defined?
Somewhere dlr has to be chuckling. We went through all of these
gyrations last summer if you want to check dev@. It was a lot harder
to get people to comment back then. Using svn log never felt right
and you would have to add a lot of new options to the command.
> 2. Should we ditch the 'svn mergeinfo' command for 1.5, and just ship
> the APIs so that TortoiseSVN, Subclipse, and other not-constrained-
> to-text-output consumers can still do their thing?
>
> 2b. Should we provide a bindings script that implements this behavior
> so 1.5 adopters can get the info, but such that we aren't stuck
> maintaining the chosen UI?
>
> Quite honestly, option 2b is looking pretty great to me right now.
As long as the API exists I do not care. Having seen this information
in a GUI I know that it is useful and it would be nice if the CLI
could do it. I think we could reach consensus around svn mergeinfo
and be done with it.
--
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 Paul Burba <pt...@gmail.com>.
On Thu, Mar 27, 2008 at 3:36 PM, C. Michael Pilato <cm...@collab.net> wrote:
>
> Mark Phippard wrote:
> > On Thu, Mar 27, 2008 at 2:21 PM, Karl Fogel <kf...@red-bean.com> wrote:
> >> Now, note that if we output revision ranges in 1.5.0, we can always
> >> switch to individual revision numbers in 1.5.1 or later, since the
> >> latter is a subset of the former anyway (unless we consider ourselves to
> >> have promised to always use ranges where possible, but I don't think we
> >> have promised that).
> >>
> >> But it would be nice to offer just one, canonical output format from the
> >> start. As you can tell, I think individual revs are much more useable.
> >> Has anyone got an objection?
> >
> > I thought we had just agreed on that. I was also suggesting my log
> > idea would also cover this. As it would be one revision per line, it
> > would just contain some additional information on each.
>
> Okay, let me try to flush my brainstate on this issue.
>
> A. Only accept a single TARGET. Everybody seems cool with this. This
> reduces indentation by one level compared to where we are today. Yay!
+1
> B. Always show log-style output, honoring both the -q and -v flags as they
> apply to 'svn log'. This gives us one revision per line (plus some other
> revision metadata) in -q case, and really useful full data in the -v case,
> plus that in-between gunk in the -qv case. This forces the output into the
> realm of needing section dividers, unless we support indentation of the log
> output. I like this.
+1
> C. We still support --from-source. But we apparently have decided to
> support *not* providing a source, we still has us trying to deal with
> multiple sets of output at once (dividers, indentation, etc.). That reduces
> the scriptability of the output's one-rev-per-lineness, because now wrappers
> have to pay attention to these section dividers and maintain state. :-(
If scriptibility is that important, than how about this (possibly
quite crazy) idea:
i) If you don't provide a --from-source but there is only *one* from
source then svn mergeinfo works. This saves users from typing
--from-source all the time, for the 1.5.x branch for example.
ii) If you don't provide a --from-source but there are *multiple*
sources, then return an error saying there are multiple sources and
one must be specified (and suggesting iii).
iii) Add --show-sources option which lists all the merge sources (one
source per line of course, allowing scripts to run this first then run
svn mergeinfo --from-source on each result).
> D. We've discussed not showing both eligible and merged [and blocked] at the
> same time, but using a switch to say which flavor of output we want. That's
> cool, because it reduces our indentation/output-sets count again. But I
> disagree with the idea of making "eligible" the default while still
> maintaining the subcommand name "mergeinfo" which to me -- admittedly
> tainted by knowledge of the internals -- means the command will show you
> information about merges, not about would-be merges that may never come to
> be. Besides, the claim that "you don't need 'svn mergeinfo' to show actual
> merges by default because 'svn pget svn:mergeinfo'" is only true when you
> happen to execute 'svn mergeinfo' on the root of a branch which said
> svn:mergeinfo property is likely to reside.
I'm still partial to showing eligible by default, but only because
that is what I'd tend to use it for. But I don't feel that strongly
about it either way. I mean honestly, does *anyone* feel that
strongly about what the default it? How about whoever codes it gets
to choose? ;-)
> If our goal is something that is machine parseable, then the easiest thing
> for scripts to parse would be:
> single-target, single-source, single-flavor, one-rev-per-line
>
> Anything more adds complications, some more easy to deal with than others.
> So what can we add that brings value to the user without crossing the line
> of machine parseability.
>
> Moving to log output, we have:
> single-target, single-source, single-flavor, one-block-of-lines-per-rev
>
> That's not so bad. But it still leaves us unable to ask, "What merges have
> been performed to TARGET from any sources?" The minute we allow multiple
> sources, the machine parseability takes a hit, and we're doing indentation
> and section headers.
>
> Since most (if not all) of the problems noted in this thread are UI related,
> not API related...:
>
> 1. Should we ditch the 'svn mergeinfo' command and roll this behavior
> into 'svn log', where we don't have to deal with
> questions of default behaviors because those are already defined?
>
> 2. Should we ditch the 'svn mergeinfo' command for 1.5, and just ship
> the APIs so that TortoiseSVN, Subclipse, and other not-constrained-
> to-text-output consumers can still do their thing?
>
> 2b. Should we provide a bindings script that implements this behavior
> so 1.5 adopters can get the info, but such that we aren't stuck
> maintaining the chosen UI?
>
> Quite honestly, option 2b is looking pretty great to me right now.
>
> --
>
>
> C. Michael Pilato <cm...@collab.net>
> CollabNet <> www.collab.net <> Distributed Development On Demand
---------------------------------------------------------------------
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>.
Mark Phippard wrote:
> On Thu, Mar 27, 2008 at 2:21 PM, Karl Fogel <kf...@red-bean.com> wrote:
>> Now, note that if we output revision ranges in 1.5.0, we can always
>> switch to individual revision numbers in 1.5.1 or later, since the
>> latter is a subset of the former anyway (unless we consider ourselves to
>> have promised to always use ranges where possible, but I don't think we
>> have promised that).
>>
>> But it would be nice to offer just one, canonical output format from the
>> start. As you can tell, I think individual revs are much more useable.
>> Has anyone got an objection?
>
> I thought we had just agreed on that. I was also suggesting my log
> idea would also cover this. As it would be one revision per line, it
> would just contain some additional information on each.
Okay, let me try to flush my brainstate on this issue.
A. Only accept a single TARGET. Everybody seems cool with this. This
reduces indentation by one level compared to where we are today. Yay!
B. Always show log-style output, honoring both the -q and -v flags as they
apply to 'svn log'. This gives us one revision per line (plus some other
revision metadata) in -q case, and really useful full data in the -v case,
plus that in-between gunk in the -qv case. This forces the output into the
realm of needing section dividers, unless we support indentation of the log
output. I like this.
C. We still support --from-source. But we apparently have decided to
support *not* providing a source, we still has us trying to deal with
multiple sets of output at once (dividers, indentation, etc.). That reduces
the scriptability of the output's one-rev-per-lineness, because now wrappers
have to pay attention to these section dividers and maintain state. :-(
D. We've discussed not showing both eligible and merged [and blocked] at the
same time, but using a switch to say which flavor of output we want. That's
cool, because it reduces our indentation/output-sets count again. But I
disagree with the idea of making "eligible" the default while still
maintaining the subcommand name "mergeinfo" which to me -- admittedly
tainted by knowledge of the internals -- means the command will show you
information about merges, not about would-be merges that may never come to
be. Besides, the claim that "you don't need 'svn mergeinfo' to show actual
merges by default because 'svn pget svn:mergeinfo'" is only true when you
happen to execute 'svn mergeinfo' on the root of a branch which said
svn:mergeinfo property is likely to reside.
If our goal is something that is machine parseable, then the easiest thing
for scripts to parse would be:
single-target, single-source, single-flavor, one-rev-per-line
Anything more adds complications, some more easy to deal with than others.
So what can we add that brings value to the user without crossing the line
of machine parseability.
Moving to log output, we have:
single-target, single-source, single-flavor, one-block-of-lines-per-rev
That's not so bad. But it still leaves us unable to ask, "What merges have
been performed to TARGET from any sources?" The minute we allow multiple
sources, the machine parseability takes a hit, and we're doing indentation
and section headers.
Since most (if not all) of the problems noted in this thread are UI related,
not API related...:
1. Should we ditch the 'svn mergeinfo' command and roll this behavior
into 'svn log', where we don't have to deal with
questions of default behaviors because those are already defined?
2. Should we ditch the 'svn mergeinfo' command for 1.5, and just ship
the APIs so that TortoiseSVN, Subclipse, and other not-constrained-
to-text-output consumers can still do their thing?
2b. Should we provide a bindings script that implements this behavior
so 1.5 adopters can get the info, but such that we aren't stuck
maintaining the chosen UI?
Quite honestly, option 2b is looking pretty great to me right now.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: RFC: svn mergeinfo improvements for 1.5
Posted by Karl Fogel <kf...@red-bean.com>.
"Mark Phippard" <ma...@gmail.com> writes:
>> But it would be nice to offer just one, canonical output format from the
>> start. As you can tell, I think individual revs are much more useable.
>> Has anyone got an objection?
>
> I thought we had just agreed on that.
Oh. Uh, somehow I missed that, and I thought I read the whole thread.
But great, then "move along folks, nothing to see here..."
> I was also suggesting my log
> idea would also cover this. As it would be one revision per line, it
> would just contain some additional information on each.
Yup.
---------------------------------------------------------------------
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 Thu, Mar 27, 2008 at 2:21 PM, Karl Fogel <kf...@red-bean.com> wrote:
> Now, note that if we output revision ranges in 1.5.0, we can always
> switch to individual revision numbers in 1.5.1 or later, since the
> latter is a subset of the former anyway (unless we consider ourselves to
> have promised to always use ranges where possible, but I don't think we
> have promised that).
>
> But it would be nice to offer just one, canonical output format from the
> start. As you can tell, I think individual revs are much more useable.
> Has anyone got an objection?
I thought we had just agreed on that. I was also suggesting my log
idea would also cover this. As it would be one revision per line, it
would just contain some additional information on each.
--
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 Karl Fogel <kf...@red-bean.com>.
A lot of this thread has focused on when to show logs (as opposed to
just the revision numbers), and on what interface to use to request
just eligible/blocked/merged revisions.
We seem to be approaching resoultion on those questions. But we still
haven't answered the question I posed in my earlier mail (and that Mike
raised before I did). Quoting from my earlier mail:
> So what happened to Mike's proposal of one rev per line?
>
> In practice, people are going to be piping through a pager or
> redirecting to a file, no matter what. Even with range compression,
> these lists only get bigger.
>
> So let's just think about it from a use case point of view. What are
> people trying to do? They're probably trying to figure out if a given
> revision has been merged and/or is eligible to be merged. The most
> useful thing would be if they could search the output *for that exact
> revision*.
>
> Also, if you do one rev per line, then filtering out no-op revisions
> really is guaranteed to shorten the output. Where as with ranges, then
> filtering out no-op revisions can increase the number of ranges, as Mike
> pointed out. Although the number of ranges will never be more than the
> number of revisions, of course, there is an inherent inconvenience in
> dealing with larger numbers of ranges -- if you're searching by eye to
> figure out what happened to a particular revision, that is.
Now, note that if we output revision ranges in 1.5.0, we can always
switch to individual revision numbers in 1.5.1 or later, since the
latter is a subset of the former anyway (unless we consider ourselves to
have promised to always use ranges where possible, but I don't think we
have promised that).
But it would be nice to offer just one, canonical output format from the
start. As you can tell, I think individual revs are much more useable.
Has anyone got an objection?
-Karl
---------------------------------------------------------------------
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 Bhuvaneswaran Arumugam <bh...@collab.net>.
On Thu, 2008-03-27 at 12:09 -0400, Mark Phippard wrote:
> On Thu, Mar 27, 2008 at 12:01 PM, Paul Burba <pt...@gmail.com> wrote:
> > So make svn mergeinfo show log output by default? That is what you
> > are saying right?
>
> Yes.
>
> > What about Bhuvan's desire to use -q to suppress merged/eligible
> > revisions for a deleted target?
>
> I do not really follow every request that has come through. I thought
> for example we were going to default to eligible revisions with a new
> option to control whether it is showing eligible|merged|blocked.
That's right. Basically, this request is a sub-set of this point in
original proposal. As per proposal, the default behavior is to show only
eligible revisions. The request is not to display eligible revisions for
a deleted target, if '-q' switch, or whichever switch we are going to
decide on, is passed.
I would even recommend to make it a default behavior. If --verbose/-v
switch is used, we could display merged/eligible revisions for a deleted
target.
--
Regards,
Bhuvaneswaran
Re: RFC: svn mergeinfo improvements for 1.5
Posted by Mark Phippard <ma...@gmail.com>.
On Thu, Mar 27, 2008 at 12:01 PM, Paul Burba <pt...@gmail.com> wrote:
> So make svn mergeinfo show log output by default? That is what you
> are saying right?
Yes.
> What about Bhuvan's desire to use -q to suppress merged/eligible
> revisions for a deleted target?
I do not really follow every request that has come through. I thought
for example we were going to default to eligible revisions with a new
option to control whether it is showing eligible|merged|blocked.
If you specify a merge source that no longer exists wouldn't it just
return an error? If we are showing log style output from multiple
sources, then I would assume any that were deleted just would not be
output, or possibly would be output with an error. I have never
understood the need to see multiple sources. If we limited the output
to one, that would make the display options a little easier.
--
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 Paul Burba <pt...@gmail.com>.
On Thu, Mar 27, 2008 at 11:50 AM, Mark Phippard <ma...@gmail.com> wrote:
>
> On Thu, Mar 27, 2008 at 11:41 AM, Paul Burba <pt...@gmail.com> wrote:
> >
> > On Wed, Mar 26, 2008 at 11:11 AM, Bhuvaneswaran Arumugam
> > <bh...@collab.net> wrote:
> > >
> > > On Tue, 2008-03-25 at 11:59 -0400, Karl Fogel wrote:
> > > > "Paul Burba" <pt...@gmail.com> writes:
> > > > > Ok, taking into account what has been said so far (including some
> > > > > off-dev conversations between Mike, Julian, and myself), how does the
> > > > > revised proposal sound?
> > > > >
> > > > > A) When displaying eligible *or* merged revisions, display only those
> > > > > that affect the merge source (i.e. don't display revisions, which
> > > > > if/when merged, would be/were no-ops). There has been some discussion
> > > > > that displaying the no-op merges might also be useful on occasion, but
> > > > > I still feel that filtering the no-ops is more useful, more of the
> > > > > time. If, after 1.5 releases, people are clamoring for the no-ops, we
> > > > > could add a --show-no-ops option. Heck, we could do this now if
> > > > > people really think there is a need.
> > > > >
> > > > > B) Support only one target, still support --from-source filter.
> > > > >
> > > > > C) By default show only eligible revisions. Add a new option
> > > > > --show-revs ARG ('merged', 'eligible'). After more thought I like
> > > > > 'eligible' as the default better, since the merged revisions are
> > > > > already represented in the svn:mergeinfo prop.
> > > >
> > > > Yay on (A), (B), and (C). See below about (D) :-).
> > > >
> > > > Regarding (C): suggest '--merged' and '--eligible' as the flag names, or
> > > > '--show-merged' and '--show-eligible'. Kind of green.bikeshed.com, I
> > > > know; maybe it doesn't make much difference. Agree about the default.
> > > >
> > > > > D) Print the revision lists as one range per line (if -v is not
> > > > > specified). This keeps things easy to read/parse, while attempting to
> > > > > avoid the excessive vertical output one rev per range more or less
> > > > > guarantees. Before you say no read E...
> > > >
> > > > So what happened to Mike's proposal of one rev per line?
> > > >
> > > > In practice, people are going to be piping through a pager or
> > > > redirecting to a file, no matter what. Even with range compression,
> > > > these lists only get bigger.
> > > >
> > > > So let's just think about it from a use case point of view. What are
> > > > people trying to do? They're probably trying to figure out if a given
> > > > revision has been merged and/or is eligible to be merged. The most
> > > > useful thing would be if they could search the output *for that exact
> > > > revision*.
> > > >
> > > > Also, if you do one rev per line, then filtering out no-op revisions
> > > > really is guaranteed to shorten the output. Where as with ranges, then
> > > > filtering out no-op revisions can increase the number of ranges, as Mike
> > > > pointed out. Although the number of ranges will never be more than the
> > > > number of revisions, of course, there is an inherent inconvenience in
> > > > dealing with larger numbers of ranges -- if you're searching by eye to
> > > > figure out what happened to a particular revision, that is.
> > > >
> > > > > E) Add support for the --verbose/-v and --quiet/-q flags. If
> > > > > specified, this produces output exactly as if doing svn log -q/-v for
> > > > > each of the eligible/merged revisions. If the --from-source option is
> > > > > specified then we don't need to indent, but if not we'll need to
> > > > > indent the log output per source. The latter is going to be a bit
> > > > > ugly, but I see no way of avoiding it.
> > > > >
> > > > > Thoughts?
> > > >
> > > > It sounds like (E) means that adding the -q flag to 'mergeinfo' would
> > > > actually cause it to give *more* output, since behaving like 'log -q'
> > > > means giving more information than just a revision number.
> > > >
> > > > That's going to be confusing. Instead, how about a --show-log flag or
> > > > something, if people want the log messages on the spot? (And then -q/-v
> > > > can be meaningful when --show-log is given. They don't have to be
> > > > meaningful without --show-log; or we can just save them to mean
> > > > something by themselves in the future.)
> > >
> > > While we're talking about adding a '-q' switch for 'mergeinfo', let me
> > > put a new request. Right now, if 'mergeinfo' is run against a deleted
> > > target, we print:
> > > Eligible revisions: (source no longer available in HEAD)
> > >
> > > Users find it convenient to provide a switch to suppress merged/eligible
> > > revisions for a deleted target. How does it sound to suppress it if '-q'
> > > switch is passed?
> >
> > I guess it makes more sense to use -q for that rather than having its
> > meaning dependent on the presence of --show-log. That leaves us with
> > the problem of how to get the different log formats when using svn
> > mergeinfo. How about just using four long options to correspond to
> > the four log formats?
> >
> > svn mergeinfo --> NO LOGS
> >
> > svn mergeinfo --show-log-q --> svn log -q
> > svn mergeinfo --show-log --> svn log
> > svn mergeinfo --show-log-q-v --> svn log -q -v
> > svn mergeinfo --show-log-v --> svn log -v
>
> Why not just always make the output follow log?
So make svn mergeinfo show log output by default? That is what you
are saying right?
What about Bhuvan's desire to use -q to suppress merged/eligible
revisions for a deleted target?
> svn mergeinfo
> svn mergeinfo -q
> svn mergeinfo -v
> svn mergeinfo -q -v
>
> If you just want one revision per line, you can use svn mergeinfo -q
>
> --
> 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 Mark Phippard <ma...@gmail.com>.
On Thu, Mar 27, 2008 at 11:41 AM, Paul Burba <pt...@gmail.com> wrote:
>
> On Wed, Mar 26, 2008 at 11:11 AM, Bhuvaneswaran Arumugam
> <bh...@collab.net> wrote:
> >
> > On Tue, 2008-03-25 at 11:59 -0400, Karl Fogel wrote:
> > > "Paul Burba" <pt...@gmail.com> writes:
> > > > Ok, taking into account what has been said so far (including some
> > > > off-dev conversations between Mike, Julian, and myself), how does the
> > > > revised proposal sound?
> > > >
> > > > A) When displaying eligible *or* merged revisions, display only those
> > > > that affect the merge source (i.e. don't display revisions, which
> > > > if/when merged, would be/were no-ops). There has been some discussion
> > > > that displaying the no-op merges might also be useful on occasion, but
> > > > I still feel that filtering the no-ops is more useful, more of the
> > > > time. If, after 1.5 releases, people are clamoring for the no-ops, we
> > > > could add a --show-no-ops option. Heck, we could do this now if
> > > > people really think there is a need.
> > > >
> > > > B) Support only one target, still support --from-source filter.
> > > >
> > > > C) By default show only eligible revisions. Add a new option
> > > > --show-revs ARG ('merged', 'eligible'). After more thought I like
> > > > 'eligible' as the default better, since the merged revisions are
> > > > already represented in the svn:mergeinfo prop.
> > >
> > > Yay on (A), (B), and (C). See below about (D) :-).
> > >
> > > Regarding (C): suggest '--merged' and '--eligible' as the flag names, or
> > > '--show-merged' and '--show-eligible'. Kind of green.bikeshed.com, I
> > > know; maybe it doesn't make much difference. Agree about the default.
> > >
> > > > D) Print the revision lists as one range per line (if -v is not
> > > > specified). This keeps things easy to read/parse, while attempting to
> > > > avoid the excessive vertical output one rev per range more or less
> > > > guarantees. Before you say no read E...
> > >
> > > So what happened to Mike's proposal of one rev per line?
> > >
> > > In practice, people are going to be piping through a pager or
> > > redirecting to a file, no matter what. Even with range compression,
> > > these lists only get bigger.
> > >
> > > So let's just think about it from a use case point of view. What are
> > > people trying to do? They're probably trying to figure out if a given
> > > revision has been merged and/or is eligible to be merged. The most
> > > useful thing would be if they could search the output *for that exact
> > > revision*.
> > >
> > > Also, if you do one rev per line, then filtering out no-op revisions
> > > really is guaranteed to shorten the output. Where as with ranges, then
> > > filtering out no-op revisions can increase the number of ranges, as Mike
> > > pointed out. Although the number of ranges will never be more than the
> > > number of revisions, of course, there is an inherent inconvenience in
> > > dealing with larger numbers of ranges -- if you're searching by eye to
> > > figure out what happened to a particular revision, that is.
> > >
> > > > E) Add support for the --verbose/-v and --quiet/-q flags. If
> > > > specified, this produces output exactly as if doing svn log -q/-v for
> > > > each of the eligible/merged revisions. If the --from-source option is
> > > > specified then we don't need to indent, but if not we'll need to
> > > > indent the log output per source. The latter is going to be a bit
> > > > ugly, but I see no way of avoiding it.
> > > >
> > > > Thoughts?
> > >
> > > It sounds like (E) means that adding the -q flag to 'mergeinfo' would
> > > actually cause it to give *more* output, since behaving like 'log -q'
> > > means giving more information than just a revision number.
> > >
> > > That's going to be confusing. Instead, how about a --show-log flag or
> > > something, if people want the log messages on the spot? (And then -q/-v
> > > can be meaningful when --show-log is given. They don't have to be
> > > meaningful without --show-log; or we can just save them to mean
> > > something by themselves in the future.)
> >
> > While we're talking about adding a '-q' switch for 'mergeinfo', let me
> > put a new request. Right now, if 'mergeinfo' is run against a deleted
> > target, we print:
> > Eligible revisions: (source no longer available in HEAD)
> >
> > Users find it convenient to provide a switch to suppress merged/eligible
> > revisions for a deleted target. How does it sound to suppress it if '-q'
> > switch is passed?
>
> I guess it makes more sense to use -q for that rather than having its
> meaning dependent on the presence of --show-log. That leaves us with
> the problem of how to get the different log formats when using svn
> mergeinfo. How about just using four long options to correspond to
> the four log formats?
>
> svn mergeinfo --> NO LOGS
>
> svn mergeinfo --show-log-q --> svn log -q
> svn mergeinfo --show-log --> svn log
> svn mergeinfo --show-log-q-v --> svn log -q -v
> svn mergeinfo --show-log-v --> svn log -v
Why not just always make the output follow log?
svn mergeinfo
svn mergeinfo -q
svn mergeinfo -v
svn mergeinfo -q -v
If you just want one revision per line, you can use svn mergeinfo -q
--
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 Paul Burba <pt...@gmail.com>.
On Wed, Mar 26, 2008 at 11:11 AM, Bhuvaneswaran Arumugam
<bh...@collab.net> wrote:
>
> On Tue, 2008-03-25 at 11:59 -0400, Karl Fogel wrote:
> > "Paul Burba" <pt...@gmail.com> writes:
> > > Ok, taking into account what has been said so far (including some
> > > off-dev conversations between Mike, Julian, and myself), how does the
> > > revised proposal sound?
> > >
> > > A) When displaying eligible *or* merged revisions, display only those
> > > that affect the merge source (i.e. don't display revisions, which
> > > if/when merged, would be/were no-ops). There has been some discussion
> > > that displaying the no-op merges might also be useful on occasion, but
> > > I still feel that filtering the no-ops is more useful, more of the
> > > time. If, after 1.5 releases, people are clamoring for the no-ops, we
> > > could add a --show-no-ops option. Heck, we could do this now if
> > > people really think there is a need.
> > >
> > > B) Support only one target, still support --from-source filter.
> > >
> > > C) By default show only eligible revisions. Add a new option
> > > --show-revs ARG ('merged', 'eligible'). After more thought I like
> > > 'eligible' as the default better, since the merged revisions are
> > > already represented in the svn:mergeinfo prop.
> >
> > Yay on (A), (B), and (C). See below about (D) :-).
> >
> > Regarding (C): suggest '--merged' and '--eligible' as the flag names, or
> > '--show-merged' and '--show-eligible'. Kind of green.bikeshed.com, I
> > know; maybe it doesn't make much difference. Agree about the default.
> >
> > > D) Print the revision lists as one range per line (if -v is not
> > > specified). This keeps things easy to read/parse, while attempting to
> > > avoid the excessive vertical output one rev per range more or less
> > > guarantees. Before you say no read E...
> >
> > So what happened to Mike's proposal of one rev per line?
> >
> > In practice, people are going to be piping through a pager or
> > redirecting to a file, no matter what. Even with range compression,
> > these lists only get bigger.
> >
> > So let's just think about it from a use case point of view. What are
> > people trying to do? They're probably trying to figure out if a given
> > revision has been merged and/or is eligible to be merged. The most
> > useful thing would be if they could search the output *for that exact
> > revision*.
> >
> > Also, if you do one rev per line, then filtering out no-op revisions
> > really is guaranteed to shorten the output. Where as with ranges, then
> > filtering out no-op revisions can increase the number of ranges, as Mike
> > pointed out. Although the number of ranges will never be more than the
> > number of revisions, of course, there is an inherent inconvenience in
> > dealing with larger numbers of ranges -- if you're searching by eye to
> > figure out what happened to a particular revision, that is.
> >
> > > E) Add support for the --verbose/-v and --quiet/-q flags. If
> > > specified, this produces output exactly as if doing svn log -q/-v for
> > > each of the eligible/merged revisions. If the --from-source option is
> > > specified then we don't need to indent, but if not we'll need to
> > > indent the log output per source. The latter is going to be a bit
> > > ugly, but I see no way of avoiding it.
> > >
> > > Thoughts?
> >
> > It sounds like (E) means that adding the -q flag to 'mergeinfo' would
> > actually cause it to give *more* output, since behaving like 'log -q'
> > means giving more information than just a revision number.
> >
> > That's going to be confusing. Instead, how about a --show-log flag or
> > something, if people want the log messages on the spot? (And then -q/-v
> > can be meaningful when --show-log is given. They don't have to be
> > meaningful without --show-log; or we can just save them to mean
> > something by themselves in the future.)
>
> While we're talking about adding a '-q' switch for 'mergeinfo', let me
> put a new request. Right now, if 'mergeinfo' is run against a deleted
> target, we print:
> Eligible revisions: (source no longer available in HEAD)
>
> Users find it convenient to provide a switch to suppress merged/eligible
> revisions for a deleted target. How does it sound to suppress it if '-q'
> switch is passed?
I guess it makes more sense to use -q for that rather than having its
meaning dependent on the presence of --show-log. That leaves us with
the problem of how to get the different log formats when using svn
mergeinfo. How about just using four long options to correspond to
the four log formats?
svn mergeinfo --> NO LOGS
svn mergeinfo --show-log-q --> svn log -q
svn mergeinfo --show-log --> svn log
svn mergeinfo --show-log-q-v --> svn log -q -v
svn mergeinfo --show-log-v --> svn log -v
Paul
> Please refer to this email thread for more details:
> http://subversion.tigris.org/servlets/BrowseList?list=dev&by=thread&from=643345
>
> OTOH, when a deleted target contains unmerged modifications, 'mergeinfo'
> does not detect it. I can't come across a clear solution for this
> problem though. Let me know if this should be tracked in an issue. A
> test recipe for this bug is available in this email:
> http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=136399
>
> Thank you!
> --
> Regards,
> Bhuvaneswaran
>
---------------------------------------------------------------------
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 Bhuvaneswaran Arumugam <bh...@collab.net>.
On Tue, 2008-03-25 at 11:59 -0400, Karl Fogel wrote:
> "Paul Burba" <pt...@gmail.com> writes:
> > Ok, taking into account what has been said so far (including some
> > off-dev conversations between Mike, Julian, and myself), how does the
> > revised proposal sound?
> >
> > A) When displaying eligible *or* merged revisions, display only those
> > that affect the merge source (i.e. don't display revisions, which
> > if/when merged, would be/were no-ops). There has been some discussion
> > that displaying the no-op merges might also be useful on occasion, but
> > I still feel that filtering the no-ops is more useful, more of the
> > time. If, after 1.5 releases, people are clamoring for the no-ops, we
> > could add a --show-no-ops option. Heck, we could do this now if
> > people really think there is a need.
> >
> > B) Support only one target, still support --from-source filter.
> >
> > C) By default show only eligible revisions. Add a new option
> > --show-revs ARG ('merged', 'eligible'). After more thought I like
> > 'eligible' as the default better, since the merged revisions are
> > already represented in the svn:mergeinfo prop.
>
> Yay on (A), (B), and (C). See below about (D) :-).
>
> Regarding (C): suggest '--merged' and '--eligible' as the flag names, or
> '--show-merged' and '--show-eligible'. Kind of green.bikeshed.com, I
> know; maybe it doesn't make much difference. Agree about the default.
>
> > D) Print the revision lists as one range per line (if -v is not
> > specified). This keeps things easy to read/parse, while attempting to
> > avoid the excessive vertical output one rev per range more or less
> > guarantees. Before you say no read E...
>
> So what happened to Mike's proposal of one rev per line?
>
> In practice, people are going to be piping through a pager or
> redirecting to a file, no matter what. Even with range compression,
> these lists only get bigger.
>
> So let's just think about it from a use case point of view. What are
> people trying to do? They're probably trying to figure out if a given
> revision has been merged and/or is eligible to be merged. The most
> useful thing would be if they could search the output *for that exact
> revision*.
>
> Also, if you do one rev per line, then filtering out no-op revisions
> really is guaranteed to shorten the output. Where as with ranges, then
> filtering out no-op revisions can increase the number of ranges, as Mike
> pointed out. Although the number of ranges will never be more than the
> number of revisions, of course, there is an inherent inconvenience in
> dealing with larger numbers of ranges -- if you're searching by eye to
> figure out what happened to a particular revision, that is.
>
> > E) Add support for the --verbose/-v and --quiet/-q flags. If
> > specified, this produces output exactly as if doing svn log -q/-v for
> > each of the eligible/merged revisions. If the --from-source option is
> > specified then we don't need to indent, but if not we'll need to
> > indent the log output per source. The latter is going to be a bit
> > ugly, but I see no way of avoiding it.
> >
> > Thoughts?
>
> It sounds like (E) means that adding the -q flag to 'mergeinfo' would
> actually cause it to give *more* output, since behaving like 'log -q'
> means giving more information than just a revision number.
>
> That's going to be confusing. Instead, how about a --show-log flag or
> something, if people want the log messages on the spot? (And then -q/-v
> can be meaningful when --show-log is given. They don't have to be
> meaningful without --show-log; or we can just save them to mean
> something by themselves in the future.)
While we're talking about adding a '-q' switch for 'mergeinfo', let me
put a new request. Right now, if 'mergeinfo' is run against a deleted
target, we print:
Eligible revisions: (source no longer available in HEAD)
Users find it convenient to provide a switch to suppress merged/eligible
revisions for a deleted target. How does it sound to suppress it if '-q'
switch is passed?
Please refer to this email thread for more details:
http://subversion.tigris.org/servlets/BrowseList?list=dev&by=thread&from=643345
OTOH, when a deleted target contains unmerged modifications, 'mergeinfo'
does not detect it. I can't come across a clear solution for this
problem though. Let me know if this should be tracked in an issue. A
test recipe for this bug is available in this email:
http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=136399
Thank you!
--
Regards,
Bhuvaneswaran
Re: RFC: svn mergeinfo improvements for 1.5
Posted by Karl Fogel <kf...@red-bean.com>.
"Paul Burba" <pt...@gmail.com> writes:
> Ok, taking into account what has been said so far (including some
> off-dev conversations between Mike, Julian, and myself), how does the
> revised proposal sound?
>
> A) When displaying eligible *or* merged revisions, display only those
> that affect the merge source (i.e. don't display revisions, which
> if/when merged, would be/were no-ops). There has been some discussion
> that displaying the no-op merges might also be useful on occasion, but
> I still feel that filtering the no-ops is more useful, more of the
> time. If, after 1.5 releases, people are clamoring for the no-ops, we
> could add a --show-no-ops option. Heck, we could do this now if
> people really think there is a need.
>
> B) Support only one target, still support --from-source filter.
>
> C) By default show only eligible revisions. Add a new option
> --show-revs ARG ('merged', 'eligible'). After more thought I like
> 'eligible' as the default better, since the merged revisions are
> already represented in the svn:mergeinfo prop.
Yay on (A), (B), and (C). See below about (D) :-).
Regarding (C): suggest '--merged' and '--eligible' as the flag names, or
'--show-merged' and '--show-eligible'. Kind of green.bikeshed.com, I
know; maybe it doesn't make much difference. Agree about the default.
> D) Print the revision lists as one range per line (if -v is not
> specified). This keeps things easy to read/parse, while attempting to
> avoid the excessive vertical output one rev per range more or less
> guarantees. Before you say no read E...
So what happened to Mike's proposal of one rev per line?
In practice, people are going to be piping through a pager or
redirecting to a file, no matter what. Even with range compression,
these lists only get bigger.
So let's just think about it from a use case point of view. What are
people trying to do? They're probably trying to figure out if a given
revision has been merged and/or is eligible to be merged. The most
useful thing would be if they could search the output *for that exact
revision*.
Also, if you do one rev per line, then filtering out no-op revisions
really is guaranteed to shorten the output. Where as with ranges, then
filtering out no-op revisions can increase the number of ranges, as Mike
pointed out. Although the number of ranges will never be more than the
number of revisions, of course, there is an inherent inconvenience in
dealing with larger numbers of ranges -- if you're searching by eye to
figure out what happened to a particular revision, that is.
> E) Add support for the --verbose/-v and --quiet/-q flags. If
> specified, this produces output exactly as if doing svn log -q/-v for
> each of the eligible/merged revisions. If the --from-source option is
> specified then we don't need to indent, but if not we'll need to
> indent the log output per source. The latter is going to be a bit
> ugly, but I see no way of avoiding it.
>
> Thoughts?
It sounds like (E) means that adding the -q flag to 'mergeinfo' would
actually cause it to give *more* output, since behaving like 'log -q'
means giving more information than just a revision number.
That's going to be confusing. Instead, how about a --show-log flag or
something, if people want the log messages on the spot? (And then -q/-v
can be meaningful when --show-log is given. They don't have to be
meaningful without --show-log; or we can just save them to mean
something by themselves in the future.)
-Karl
---------------------------------------------------------------------
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 Paul Burba <pt...@gmail.com>.
On Tue, Mar 18, 2008 at 10:52 PM, Troy Curtis Jr <tr...@gmail.com> wrote:
> On Tue, Mar 18, 2008 at 9:33 PM, C. Michael Pilato <cm...@collab.net> wrote:
> > Troy Curtis Jr wrote:
> > >> A) When displaying eligible revisions display only those that affect
> > >> the merge source (i.e. don't display revisions, which if merged, would
> > >> be no-ops).
> > >
> > > I haven't played with the merge-tracking features in 1.5 too much yet, so it
> > > blows my mind that this isn't already true. That would go a long way toward
> > > de-cluttering the output for sure!
> >
> > Actually, it doesn't. This change (which I've implemented, by the way) has
> > just as much of a chance of making the output *larger* as it does of making
> > it smaller. Why? Because where today it might claim that "r4:10" is
> > eligible for merge, taking into account that maybe r8 is a noop means that
> > displaying the list of *real* merges now actually expands to "r4:7, r8:10".
> >
>
> Good point! Now that you say that I can remember several time when I wish
> svnmerge.py would have been smart enough to include the no-op revs in a single
> merge operation. There have been times when splitting up the range caused two
> separate merge operations which in turn caused needless conflicts. I guess I
> just popped off without really thinking about it.
>
>
> >
> >
> > >> B) Support only one target, still support --from-source filter.
> > >>
> > >> C) By default show only merged revisions. Add a new option
> > >> --merged-revs ARG ('merged', 'eligible'). Yes, as things stand now,
> > >> it would make more sense to just use an option like '--show-eligible',
> > >> but we want to be ready for the day when true revision blocking is
> > >> available so we can easily see --merged-revs=blocked.
> > >>
> > >
> > > At the risk of bike-shedding a little I do have a suggestion here. Change the
> > > '--merged-revs' to something like '--display-revs'. The option
> > > '--merged-revs=blocked' and '--merged-revs=eligible' doesn't "read"
> > > quite right.
> > > But '--display-revs=eligible' immediately says what it is doing: Displaying the
> > > eligible revisions.
> >
> > I think we toyed with the idea of --show-revs or --mergeinfo-kind or
> > something, too.
> >
> >
> > > I also think the default should be show eligible ranges since that tends to be
> > > the more interesting case. Otherwise I think people will effectively have to
> > > type this EVERY innovaction of the mergeinfo subcommand:
> > >
> > > svn mergeinfo --display-revs=eligible
> >
> > Well, yes, if you assume that people will use 'svn mergeinfo' mostly to see
> > what needs to be merged versus what has already been merged, that's true.
> > But I think the jury is out on whether that is reality. (I suspect they
> > won't use 'svn mergeinfo' at all if we don't make some of these changes
> > which facilitate associated eligible-revs with log messages they can use to
> > review those revs.)
> >
>
> I think that your parenthetical is right on the money...I rarely look at the
> raw list, it just isn't that useful in general because revisions don't really
> MEAN anything. In fact, the first script I would write when I seriously started
> using 1.5 would be something to parse the merge-info output and give me the
> log messages (which would be that much easier with one range per line).
>
> I guess I'm a victim of not being able to effectively see past
> my group's use of the svnmerge script for merge-tracking. I basically think
> of the mergeinfo tool as a way to get a list of eligible ranges. In fact,
> when I first looked at the merge-tracking changes to Subversion, the first
> thing I looked for was "How do I see the list of available revisions to
> merge?"
>
> Perhaps we should take a poll of all the current users of svnmerge.py and see
> what they want to look for most of the time?
>
>
> >
> > >> D) Print the revision lists as one range per line, e.g.:
> > >>
> > >> >svn mergeinfo \svn\src-branch --merged-revs eligible
> > >> Source path: /trunk
> > >> Eligible ranges:
> > >> r29080:29084
> > >> r29089:29090
> > >> r29091:29093
> > >> r29107:29110
> > >> .
> > >> <snip>
> > >> .
> > >> r29869:29877
> > >> r29878:29882
> > >> r29884:29943
> > >>
> > >
> > > Much more readable, even if you do have to pipe it to a pager to make it
> > > useful. :)
> >
> > Actually, Julian and I were now thinking we should print one revision per
> > line. If you think about it, in any decently sized project with many active
> > branches, the chances of having contiguous revisions eligible for merge for
> > a given source degrades quickly (because commits from various branches are
> > all interleaved). So why not pre-emptively do one revision per line, which
> > sort of naturally expands to adding a --verbose flag that turns those into
> > blocks of 'svn log' output?
>
> I think that is probably true, I'm pretty sure it's true with my projects at
> work. However, it just seems wrong, especially if you think of looking at the
> 'merged' revisions. In my project you'd get 30000-40000 lines right at the
> top, instead of:
> r1:50000
>
> Which might be very distracting. If a large project naturally fragments,
> then let it fragment. In the "worse" case they'll have one rev per
> line...but at least the smaller guys won't have to see the same thing.
> >
> > --
>
> > C. Michael Pilato <cm...@collab.net>
> > CollabNet <> www.collab.net <> Distributed Development On Demand
> >
> >
>
>
>
> Troy
Ok, taking into account what has been said so far (including some
off-dev conversations between Mike, Julian, and myself), how does the
revised proposal sound?
A) When displaying eligible *or* merged revisions, display only those
that affect the merge source (i.e. don't display revisions, which
if/when merged, would be/were no-ops). There has been some discussion
that displaying the no-op merges might also be useful on occasion, but
I still feel that filtering the no-ops is more useful, more of the
time. If, after 1.5 releases, people are clamoring for the no-ops, we
could add a --show-no-ops option. Heck, we could do this now if
people really think there is a need.
B) Support only one target, still support --from-source filter.
C) By default show only eligible revisions. Add a new option
--show-revs ARG ('merged', 'eligible'). After more thought I like
'eligible' as the default better, since the merged revisions are
already represented in the svn:mergeinfo prop.
D) Print the revision lists as one range per line (if -v is not
specified). This keeps things easy to read/parse, while attempting to
avoid the excessive vertical output one rev per range more or less
guarantees. Before you say no read E...
E) Add support for the --verbose/-v and --quiet/-q flags. If
specified, this produces output exactly as if doing svn log -q/-v for
each of the eligible/merged revisions. If the --from-source option is
specified then we don't need to indent, but if not we'll need to
indent the log output per source. The latter is going to be a bit
ugly, but I see no way of avoiding it.
Thoughts?
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 Troy Curtis Jr <tr...@gmail.com>.
On Tue, Mar 18, 2008 at 9:33 PM, C. Michael Pilato <cm...@collab.net> wrote:
> Troy Curtis Jr wrote:
> >> A) When displaying eligible revisions display only those that affect
> >> the merge source (i.e. don't display revisions, which if merged, would
> >> be no-ops).
> >
> > I haven't played with the merge-tracking features in 1.5 too much yet, so it
> > blows my mind that this isn't already true. That would go a long way toward
> > de-cluttering the output for sure!
>
> Actually, it doesn't. This change (which I've implemented, by the way) has
> just as much of a chance of making the output *larger* as it does of making
> it smaller. Why? Because where today it might claim that "r4:10" is
> eligible for merge, taking into account that maybe r8 is a noop means that
> displaying the list of *real* merges now actually expands to "r4:7, r8:10".
>
Good point! Now that you say that I can remember several time when I wish
svnmerge.py would have been smart enough to include the no-op revs in a single
merge operation. There have been times when splitting up the range caused two
separate merge operations which in turn caused needless conflicts. I guess I
just popped off without really thinking about it.
>
>
> >> B) Support only one target, still support --from-source filter.
> >>
> >> C) By default show only merged revisions. Add a new option
> >> --merged-revs ARG ('merged', 'eligible'). Yes, as things stand now,
> >> it would make more sense to just use an option like '--show-eligible',
> >> but we want to be ready for the day when true revision blocking is
> >> available so we can easily see --merged-revs=blocked.
> >>
> >
> > At the risk of bike-shedding a little I do have a suggestion here. Change the
> > '--merged-revs' to something like '--display-revs'. The option
> > '--merged-revs=blocked' and '--merged-revs=eligible' doesn't "read"
> > quite right.
> > But '--display-revs=eligible' immediately says what it is doing: Displaying the
> > eligible revisions.
>
> I think we toyed with the idea of --show-revs or --mergeinfo-kind or
> something, too.
>
>
> > I also think the default should be show eligible ranges since that tends to be
> > the more interesting case. Otherwise I think people will effectively have to
> > type this EVERY innovaction of the mergeinfo subcommand:
> >
> > svn mergeinfo --display-revs=eligible
>
> Well, yes, if you assume that people will use 'svn mergeinfo' mostly to see
> what needs to be merged versus what has already been merged, that's true.
> But I think the jury is out on whether that is reality. (I suspect they
> won't use 'svn mergeinfo' at all if we don't make some of these changes
> which facilitate associated eligible-revs with log messages they can use to
> review those revs.)
>
I think that your parenthetical is right on the money...I rarely look at the
raw list, it just isn't that useful in general because revisions don't really
MEAN anything. In fact, the first script I would write when I seriously started
using 1.5 would be something to parse the merge-info output and give me the
log messages (which would be that much easier with one range per line).
I guess I'm a victim of not being able to effectively see past
my group's use of the svnmerge script for merge-tracking. I basically think
of the mergeinfo tool as a way to get a list of eligible ranges. In fact,
when I first looked at the merge-tracking changes to Subversion, the first
thing I looked for was "How do I see the list of available revisions to
merge?"
Perhaps we should take a poll of all the current users of svnmerge.py and see
what they want to look for most of the time?
>
> >> D) Print the revision lists as one range per line, e.g.:
> >>
> >> >svn mergeinfo \svn\src-branch --merged-revs eligible
> >> Source path: /trunk
> >> Eligible ranges:
> >> r29080:29084
> >> r29089:29090
> >> r29091:29093
> >> r29107:29110
> >> .
> >> <snip>
> >> .
> >> r29869:29877
> >> r29878:29882
> >> r29884:29943
> >>
> >
> > Much more readable, even if you do have to pipe it to a pager to make it
> > useful. :)
>
> Actually, Julian and I were now thinking we should print one revision per
> line. If you think about it, in any decently sized project with many active
> branches, the chances of having contiguous revisions eligible for merge for
> a given source degrades quickly (because commits from various branches are
> all interleaved). So why not pre-emptively do one revision per line, which
> sort of naturally expands to adding a --verbose flag that turns those into
> blocks of 'svn log' output?
I think that is probably true, I'm pretty sure it's true with my projects at
work. However, it just seems wrong, especially if you think of looking at the
'merged' revisions. In my project you'd get 30000-40000 lines right at the
top, instead of:
r1:50000
Which might be very distracting. If a large project naturally fragments,
then let it fragment. In the "worse" case they'll have one rev per
line...but at least the smaller guys won't have to see the same thing.
>
> --
> C. Michael Pilato <cm...@collab.net>
> CollabNet <> www.collab.net <> Distributed Development On Demand
>
>
Troy
--
Beware of spyware. If you can, use the Firefox browser. - USA Today
Download now at http://getfirefox.com
Registered Linux User #354814 ( http://counter.li.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>.
Troy Curtis Jr wrote:
>> A) When displaying eligible revisions display only those that affect
>> the merge source (i.e. don't display revisions, which if merged, would
>> be no-ops).
>
> I haven't played with the merge-tracking features in 1.5 too much yet, so it
> blows my mind that this isn't already true. That would go a long way toward
> de-cluttering the output for sure!
Actually, it doesn't. This change (which I've implemented, by the way) has
just as much of a chance of making the output *larger* as it does of making
it smaller. Why? Because where today it might claim that "r4:10" is
eligible for merge, taking into account that maybe r8 is a noop means that
displaying the list of *real* merges now actually expands to "r4:7, r8:10".
>> B) Support only one target, still support --from-source filter.
>>
>> C) By default show only merged revisions. Add a new option
>> --merged-revs ARG ('merged', 'eligible'). Yes, as things stand now,
>> it would make more sense to just use an option like '--show-eligible',
>> but we want to be ready for the day when true revision blocking is
>> available so we can easily see --merged-revs=blocked.
>>
>
> At the risk of bike-shedding a little I do have a suggestion here. Change the
> '--merged-revs' to something like '--display-revs'. The option
> '--merged-revs=blocked' and '--merged-revs=eligible' doesn't "read"
> quite right.
> But '--display-revs=eligible' immediately says what it is doing: Displaying the
> eligible revisions.
I think we toyed with the idea of --show-revs or --mergeinfo-kind or
something, too.
> I also think the default should be show eligible ranges since that tends to be
> the more interesting case. Otherwise I think people will effectively have to
> type this EVERY innovaction of the mergeinfo subcommand:
>
> svn mergeinfo --display-revs=eligible
Well, yes, if you assume that people will use 'svn mergeinfo' mostly to see
what needs to be merged versus what has already been merged, that's true.
But I think the jury is out on whether that is reality. (I suspect they
won't use 'svn mergeinfo' at all if we don't make some of these changes
which facilitate associated eligible-revs with log messages they can use to
review those revs.)
>> D) Print the revision lists as one range per line, e.g.:
>>
>> >svn mergeinfo \svn\src-branch --merged-revs eligible
>> Source path: /trunk
>> Eligible ranges:
>> r29080:29084
>> r29089:29090
>> r29091:29093
>> r29107:29110
>> .
>> <snip>
>> .
>> r29869:29877
>> r29878:29882
>> r29884:29943
>>
>
> Much more readable, even if you do have to pipe it to a pager to make it
> useful. :)
Actually, Julian and I were now thinking we should print one revision per
line. If you think about it, in any decently sized project with many active
branches, the chances of having contiguous revisions eligible for merge for
a given source degrades quickly (because commits from various branches are
all interleaved). So why not pre-emptively do one revision per line, which
sort of naturally expands to adding a --verbose flag that turns those into
blocks of 'svn log' output?
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: RFC: svn mergeinfo improvements for 1.5
Posted by Troy Curtis Jr <tr...@gmail.com>.
On Tue, Mar 18, 2008 at 3:49 PM, Paul Burba <pt...@gmail.com> wrote:
> Today the svn mergeinfo command gives basic information on what
> revisions have been merged to a path and what revisions are eligible
> to be merged to that path, e.g.:
>
>
> >svn mergeinfo merge_tests-90\A_COPY
> Path: merge_tests-90\A_COPY
> Source path: /A
> Merged ranges: r1:6
> Eligible ranges: r6:7
>
>
> This meets our basic requirement for change set availability auditing,
> see http://svn.collab.net/repos/svn/trunk/www/merge-tracking/requirements.html#change-set-availability
>
> There are some problems though:
>
> 1) The eligible ranges can include revisions that don't apply to the
> merge source, see
> http://subversion.tigris.org/issues/show_bug.cgi?id=3126
>
> 2) You can specify multiple targets but only one --from-source, is
> this ever going to be useful? Is the support of multiple targets even
> that useful? It adds another level of indentation to the output,
> which is already a bit ugly to start with (see 3).
>
> 3) When there are a *lot* of merged/eligible ranges then the output is
> not easily parsed. Look at a 1.5.x WC for example:
>
> >svn mergeinfo \svn\src-branch
> Path: \SVN\src-branch
> Source path: /trunk
> Merged ranges: r0:29080, r29084:29089, r29090:29091, r29093:29107,
> r29110:29111, r29113:29114, r29116:29117, r29125:29127, r29128:29133,
> r29134:29150,
> r29152:29164, r29165:29166, r29173:29174, r29175:29186, r29187:29189,
> r29192:29194, r29197:29200, r29201:29206, r29207:29251, r29253:29256,
> r29260:29261, r
> 29266:29273, r29276:29277, r29279:29281, r29283:29284, r29286:29303,
> r29304:29307, r29308:29325, r29326:29343, r29344:29348, r29357:29379,
> r29380:29392, r2
> 9396:29397, r29398:29399, r29400:29401, r29408:29409, r29411:29412,
> r29413:29415, r29416:29423, r29424:29426, r29428:29429, r29432:29434,
> r29435:29438, r29
> 439:29447, r29448:29466, r29467:29478, r29481:29482, r29483:29484,
> r29485:29487, r29488:29489, r29490:29491, r29492:29493, r29495:29496,
> r29497:29498, r295
> 07:29508, r29526:29528, r29530:29531, r29532:29533, r29538:29540,
> r29541:29542, r29543:29544, r29545:29546, r29550:29551, r29552:29553,
> r29555:29556, r2955
> 8:29559, r29564:29565, r29566:29569, r29570:29578, r29580:29581,
> r29582:29583, r29590:29591, r29593:29594, r29599:29600, r29602:29603,
> r29606:29607, r29610
> :29611, r29612:29614, r29618:29619, r29622:29623, r29624:29626,
> r29629:29631, r29633:29634, r29641:29642, r29647:29648, r29649:29650,
> r29655:29656, r29658:
> 29660, r29662:29664, r29670:29672, r29676:29680, r29691:29692,
> r29737:29739, r29741:29744, r29745:29746, r29750:29751, r29762:29763,
> r29768:29770, r29783:2
> 9784, r29786:29787, r29820:29821, r29823:29824, r29827:29828,
> r29834:29835, r29854:29855, r29867:29869, r29877:29878, r29882:29884
> Eligible ranges: r29080:29084, r29089:29090, r29091:29093,
> r29107:29110, r29111:29113, r29114:29116, r29117:29125, r29127:29128,
> r29133:29134, r29150:2
> 9152, r29164:29165, r29166:29173, r29174:29175, r29186:29187,
> r29189:29192, r29194:29197, r29200:29201, r29206:29207, r29251:29253,
> r29256:29260, r29261:29
> 266, r29273:29276, r29277:29279, r29281:29283, r29284:29286,
> r29303:29304, r29307:29308, r29325:29326, r29343:29344, r29348:29357,
> r29379:29380, r29392:293
> 96, r29397:29398, r29399:29400, r29401:29408, r29409:29411,
> r29412:29413, r29415:29416, r29423:29424, r29426:29428, r29429:29432,
> r29434:29435, r29438:2943
> 9, r29447:29448, r29466:29467, r29478:29481, r29482:29483,
> r29484:29485, r29487:29488, r29489:29490, r29491:29492, r29493:29495,
> r29496:29497, r29498:29507
> , r29508:29526, r29528:29530, r29531:29532, r29533:29538,
> r29540:29541, r29542:29543, r29544:29545, r29546:29550, r29551:29552,
> r29553:29555, r29556:29558,
> r29559:29564, r29565:29566, r29569:29570, r29578:29580, r29581:29582,
> r29583:29590, r29591:29593, r29594:29599, r29600:29602, r29603:29606,
> r29607:29610,
> r29611:29612, r29614:29618, r29619:29622, r29623:29624, r29626:29629,
> r29631:29633, r29634:29641, r29642:29647, r29648:29649, r29650:29655,
> r29656:29658, r
> 29660:29662, r29664:29670, r29672:29676, r29680:29691, r29692:29737,
> r29739:29741, r29744:29745, r29746:29750, r29751:29762, r29763:29768,
> r29770:29783, r2
> 9784:29786, r29787:29820, r29821:29823, r29824:29827, r29828:29834,
> r29835:29854, r29855:29867, r29869:29877, r29878:29882, r29884:29943
>
> Ouch! For the merged ranges this is little better than doing a propget:
>
> >svn pg svn:mergeinfo \svn\src-branch
> /trunk:1-29080,29085-29089,29091,29094-29107,29111,29114,29117,29126-29127,29129-29133,29135-29150,29153-29164,29166,29174,29176-29186,29188-29189,29193-29
> 194,29198-29200,29202-29206,29208-29251,29254-29256,29261,29267-29273,29277,29280-29281,29284,29287-29303,29305-29307,29309-29325,29327-29343,29345-29348,2
> 9358-29379,29381-29392,29397,29399,29401,29409,29412,29414-29415,29417-29423,29425-29426,29429,29433-29434,29436-29438,29440-29447,29449-29466,29468-29478,
> 29482,29484,29486-29487,29489,29491,29493,29496,29498,29508,29527-29528,29531,29533,29539-29540,29542,29544,29546,29551,29553,29556,29559,29565,29567-29569
> ,29571-29578,29581,29583,29591,29594,29600,29603,29607,29611,29613-29614,29619,29623,29625-29626,29630-29631,29634,29642,29648,29650,29656,29659-29660,2966
> 3-29664,29671-29672,29677-29680,29692,29738-29739,29742-29744,29746,29751,29763,29769-29770,29784,29787,29821,29824,29828,29835,29855,29868-29869,29878,298
>
> ~~~~~
>
> Anyway, Mike, Julian, and I were discussing these problems today and
> came to a consensus that the following changes would be nice to get
> into 1.5:
>
> A) When displaying eligible revisions display only those that affect
> the merge source (i.e. don't display revisions, which if merged, would
> be no-ops).
I haven't played with the merge-tracking features in 1.5 too much yet, so it
blows my mind that this isn't already true. That would go a long way toward
de-cluttering the output for sure!
>
> B) Support only one target, still support --from-source filter.
>
> C) By default show only merged revisions. Add a new option
> --merged-revs ARG ('merged', 'eligible'). Yes, as things stand now,
> it would make more sense to just use an option like '--show-eligible',
> but we want to be ready for the day when true revision blocking is
> available so we can easily see --merged-revs=blocked.
>
At the risk of bike-shedding a little I do have a suggestion here. Change the
'--merged-revs' to something like '--display-revs'. The option
'--merged-revs=blocked' and '--merged-revs=eligible' doesn't "read"
quite right.
But '--display-revs=eligible' immediately says what it is doing: Displaying the
eligible revisions.
I also think the default should be show eligible ranges since that tends to be
the more interesting case. Otherwise I think people will effectively have to
type this EVERY innovaction of the mergeinfo subcommand:
svn mergeinfo --display-revs=eligible
That's a lot of typing for something that you need to use frequently. Thus
far at work very very few times have I executed a command to determine what
HAS been merged, it's always to determine what HAS NOT been merged. I don't
think I am alone here, as the svnmerge script has a command NAMED 'available'.
> D) Print the revision lists as one range per line, e.g.:
>
> >svn mergeinfo \svn\src-branch --merged-revs eligible
> Source path: /trunk
> Eligible ranges:
> r29080:29084
> r29089:29090
> r29091:29093
> r29107:29110
> .
> <snip>
> .
> r29869:29877
> r29878:29882
> r29884:29943
>
Much more readable, even if you do have to pipe it to a pager to make it
useful. :)
>
> These changes make svn mergeinfo a bit more useful today, while
> allowing subsequent changes in 1.6 to be made based on user feedback
> (e.g. --verbose could show log info for merged/eligible revisions).
>
> Any objections to these changes and/or the goal of getting them into
> 1.5? Alternate suggestions?
>
Personally the lack of supporting true block operations in 1.5 is a deal
breaker for using it at work, so I don't have an opinion on getting it into
1.5. However, I do think those suggestions will go a long way to improving
the usefullness of the mergeinfo command.
> Paul
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
Troy
--
Beware of spyware. If you can, use the Firefox browser. - USA Today
Download now at http://getfirefox.com
Registered Linux User #354814 ( http://counter.li.org/)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org