-1 from me. The functionality can be gained using a wrapper script
(which we could certainly keep in our own contrib/ area), and the
maintenance cost of a first-class feature just wouldn't see payoff.
Resolve/WONTFIX?
Daniel Rall wrote:
> I'm not in favor of this change. I don't believe that 'update' is the
> appropriate place to be retrieving change log information. Thoughts?
>
> On Sun, 03 Dec 2006, salty_horse@tigris.org wrote:
>
>> http://subversion.tigris.org/issues/show_bug.cgi?id=2672
>> Issue #|2672
>> Summary|--show-log flag for "svn update"
>> Component|subversion
>> Version|---
>> Platform|All
>> URL|
>> OS/Version|All
>> Status|NEW
>> Status whiteboard|
>> Keywords|
>> Resolution|
>> Issue type|ENHANCEMENT
>> Priority|P5
>> Subcomponent|cmdline client
>> Assigned to|issues@subversion
>> Reported by|salty_horse
>>
>>
>>
>>
>>
>>
>> ------- Additional comments from salty_horse@tigris.org Sun Dec 3 12:01:49 -0800 2006 -------
>> "svn up --show-log" will print the usual file modification output, and
>> afterwards will print an "svn log"-style output of all the revisions between the
>> current and the new one.
>>
>> This is an absolute nice-to-have. I can already get that information in a
>> variety of ways, but the best one would be built into the client. Some of them:
>>
>> * running "svn info" to see the current revision, updating, and then running
>> "svn log" against the old revision. I consider too much work - a wrapper script
>> would fix that, but maybe other people would be interested in the feature.
>>
>> * following the commit emails. But these are useful for developers who like to
>> review the code. As an end-user who uses a bleeding-edge application and simply
>> likes to know "what's new since the last time I compiled", commit emails aren't
>> the best solution.
--
C. Michael Pilato <cmpilato@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on Mon Dec 4 20:00:20 2006