You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Vincent Lefevre <vi...@vinc17.org> on 2008/06/06 12:27:05 UTC

svn log -v and status of affected paths: 2 columns?

The status of affected paths output by "svn log -v" has one column
only, contrary to "svn status", which uses two columns: one for the
contents and one for the properties. Is the behavior of "svn log -v"
intentional? Wouldn't it be better to distinguish contents and
properties in "svn log -v" output too?

FYI, I could only find this reference about affected paths:

  http://subversion.tigris.org/servlets/ReadMsg?list=dev&&msgNo=90467

-- 
Vincent Lefèvre <vi...@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: svn log -v and status of affected paths: 2 columns?

Posted by Daniel Shahaf <d....@daniel.shahaf.co.il>.
Mark Phippard wrote on Fri, 6 Jun 2008 at 12:07 -0400:
> On Fri, Jun 6, 2008 at 11:55 AM, Karl Fogel <kf...@red-bean.com> wrote:
> > Vincent Lefevre <vi...@vinc17.org> writes:
> >> The status of affected paths output by "svn log -v" has one column
> >> only, contrary to "svn status", which uses two columns: one for the
> >> contents and one for the properties. Is the behavior of "svn log -v"
> >> intentional? Wouldn't it be better to distinguish contents and
> >> properties in "svn log -v" output too?
> >>
> >> FYI, I could only find this reference about affected paths:
> >>
> >>   http://subversion.tigris.org/servlets/ReadMsg?list=dev&&msgNo=90467
> >
> > The decision not to reflect that difference was deliberate, as log is
> > just a summary of what changed.  We haven't heard a lot of clamoring for
> > it to distinguish, so I'm not sure there's a pressing need to change
> > it... (not even getting into compatibility concerns).
> 

If it were available, branch logs would be easier to read:

	% svn log -v -r31592
	------------------------------------------------------------------------
	r31592 | stsp | 2008-06-04 22:54:36 +0300 (Wed, 04 Jun 2008) | 8 lines
	Changed paths:
	   M /branches/1.5.x
	   M /branches/1.5.x/CHANGES
	   M /branches/1.5.x/COMMITTERS
	   M /branches/1.5.x/INSTALL
	   M /branches/1.5.x/STATUS
	   M /branches/1.5.x/subversion/bindings/swig

	On the 1.5.x branch, merge r29432 from trunk.

	* INSTALL: Mention support for Neon 0.28.
	* STATUS: Remove entry for r29432.

	Approved by: danielsh
	             hwright

	------------------------------------------------------------------------

I don't have an opinion either way, though, and this problem isn't unique 
to 'svn log'.

Daniel

> I recall this coming up after 1.0 and something about the way this was
> implemented would require a 2.0 to change.  I am not sure how true
> that is given some of the other changes we have managed to make since
> then.  I am pretty sure this information is not transmitted from the
> server to client currently though, so it is not a trivial matter to
> just add it.
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: svn log -v and status of affected paths: 2 columns?

Posted by "C. Michael Pilato" <cm...@collab.net>.
Eric Gillespie wrote:
> "C. Michael Pilato" <cm...@collab.net> writes:
> 
>> Oops -- I mispoke earlier when I said that this information already=20
>> available in the log structures.  What you get today is just "props=20
>> were/weren't changed", not the full added/modified/deleted status for=20
>> properties.
> 
> svn_log_entry_t doesn't have anything at all about properties,
> only action (char) and copyfrom.

WHAT?!  Oh, that's *right*.  The prop_mod flag is in the 
svn_fs_path_change_t, and we drop that when creating svn_log_changed_path_t 
from it.  Bummer.

-- 
C. Michael Pilato <cm...@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand


Re: svn log -v and status of affected paths: 2 columns?

Posted by Eric Gillespie <ep...@pretzelnet.org>.
"C. Michael Pilato" <cm...@collab.net> writes:

> Oops -- I mispoke earlier when I said that this information already=20
> available in the log structures.  What you get today is just "props=20
> were/weren't changed", not the full added/modified/deleted status for=20
> properties.

svn_log_entry_t doesn't have anything at all about properties,
only action (char) and copyfrom.

> Another thing folks have asked for often (and I personally would love to =
> 
> see) is the change to have log's changed-paths carry a `kind' field (file=
> ,=20
> directory, etc.).  That is something we don't store with the changes in t=
> he=20
> repositories, and, while easy to calculate at log-time, adds expense.  An=

Not much expense, I'm sure.  I, too, would like to see this.
Adding prop_action would probably be more difficult, but I'd like
to see that too :).

--  
Eric Gillespie <*> epg@pretzelnet.org

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: svn log -v and status of affected paths: 2 columns?

Posted by "C. Michael Pilato" <cm...@collab.net>.
Mark Phippard wrote:
> On Fri, Jun 6, 2008 at 11:55 AM, Karl Fogel <kf...@red-bean.com> wrote:
>> Vincent Lefevre <vi...@vinc17.org> writes:
>>> The status of affected paths output by "svn log -v" has one column
>>> only, contrary to "svn status", which uses two columns: one for the
>>> contents and one for the properties. Is the behavior of "svn log -v"
>>> intentional? Wouldn't it be better to distinguish contents and
>>> properties in "svn log -v" output too?
>>>
>>> FYI, I could only find this reference about affected paths:
>>>
>>>   http://subversion.tigris.org/servlets/ReadMsg?list=dev&&msgNo=90467
>> The decision not to reflect that difference was deliberate, as log is
>> just a summary of what changed.  We haven't heard a lot of clamoring for
>> it to distinguish, so I'm not sure there's a pressing need to change
>> it... (not even getting into compatibility concerns).
> 
> I recall this coming up after 1.0 and something about the way this was
> implemented would require a 2.0 to change.  I am not sure how true
> that is given some of the other changes we have managed to make since
> then.  I am pretty sure this information is not transmitted from the
> server to client currently though, so it is not a trivial matter to
> just add it.

Oops -- I mispoke earlier when I said that this information already 
available in the log structures.  What you get today is just "props 
were/weren't changed", not the full added/modified/deleted status for 
properties.

Another thing folks have asked for often (and I personally would love to 
see) is the change to have log's changed-paths carry a `kind' field (file, 
directory, etc.).  That is something we don't store with the changes in the 
repositories, and, while easy to calculate at log-time, adds expense.  And, 
of course, the wire formats would need to be adjusted, as would the 
svn_log_path_changed_t (unless we suddenly started allowing directories to 
carry trailing slashes as a "kind" flag).

-- 
C. Michael Pilato <cm...@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand


Re: svn log -v and status of affected paths: 2 columns?

Posted by Mark Phippard <ma...@gmail.com>.
On Fri, Jun 6, 2008 at 11:55 AM, Karl Fogel <kf...@red-bean.com> wrote:
> Vincent Lefevre <vi...@vinc17.org> writes:
>> The status of affected paths output by "svn log -v" has one column
>> only, contrary to "svn status", which uses two columns: one for the
>> contents and one for the properties. Is the behavior of "svn log -v"
>> intentional? Wouldn't it be better to distinguish contents and
>> properties in "svn log -v" output too?
>>
>> FYI, I could only find this reference about affected paths:
>>
>>   http://subversion.tigris.org/servlets/ReadMsg?list=dev&&msgNo=90467
>
> The decision not to reflect that difference was deliberate, as log is
> just a summary of what changed.  We haven't heard a lot of clamoring for
> it to distinguish, so I'm not sure there's a pressing need to change
> it... (not even getting into compatibility concerns).

I recall this coming up after 1.0 and something about the way this was
implemented would require a 2.0 to change.  I am not sure how true
that is given some of the other changes we have managed to make since
then.  I am pretty sure this information is not transmitted from the
server to client currently though, so it is not a trivial matter to
just add 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: svn log -v and status of affected paths: 2 columns?

Posted by "C. Michael Pilato" <cm...@collab.net>.
Karl Fogel wrote:
> Vincent Lefevre <vi...@vinc17.org> writes:
>> The status of affected paths output by "svn log -v" has one column
>> only, contrary to "svn status", which uses two columns: one for the
>> contents and one for the properties. Is the behavior of "svn log -v"
>> intentional? Wouldn't it be better to distinguish contents and
>> properties in "svn log -v" output too?
>>
>> FYI, I could only find this reference about affected paths:
>>
>>   http://subversion.tigris.org/servlets/ReadMsg?list=dev&&msgNo=90467
> 
> The decision not to reflect that difference was deliberate, as log is
> just a summary of what changed.  We haven't heard a lot of clamoring for
> it to distinguish, so I'm not sure there's a pressing need to change
> it... (not even getting into compatibility concerns).

Also, folks who care enough can write (or commission the writing of) 
software against svn_client_logX() and get the additional info they need 
today, with no changes to Subversion itself.

-- 
C. Michael Pilato <cm...@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand


Re: svn log -v and status of affected paths: 2 columns?

Posted by Karl Fogel <kf...@red-bean.com>.
Vincent Lefevre <vi...@vinc17.org> writes:
> The status of affected paths output by "svn log -v" has one column
> only, contrary to "svn status", which uses two columns: one for the
> contents and one for the properties. Is the behavior of "svn log -v"
> intentional? Wouldn't it be better to distinguish contents and
> properties in "svn log -v" output too?
>
> FYI, I could only find this reference about affected paths:
>
>   http://subversion.tigris.org/servlets/ReadMsg?list=dev&&msgNo=90467

The decision not to reflect that difference was deliberate, as log is
just a summary of what changed.  We haven't heard a lot of clamoring for
it to distinguish, so I'm not sure there's a pressing need to change
it... (not even getting into compatibility concerns).

-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org