[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] Was: Enhancement needed in svn status -u

From: Mark Phippard <MarkP_at_softlanding.com>
Date: 2005-08-23 22:54:31 CEST

Daniel Rall <dlr@finemaltcoding.com> wrote on 08/23/2005 04:47:55 PM:

> On Tue, 23 Aug 2005, Paul Burba wrote:
> > Mark Phippard <MarkP@softlanding.com> wrote on 08/23/2005 10:37:31 AM:
> ...
> > > In summary, I would propose that at a minimum we ditch the new URL
> > > kind fields from this structure and instead update the existing
fields in
> > > the cases that we currently do not (new files in repos). I also
think it
> > > is worthy of consideration that we do the same for the other three
> > > (revision, date, and author). However, since changing those fields
> > > visibly change the output of status, I can see where some people
> > > be against that. To me, it seems like a better way to change this.
> This is a significant change in behavior for the 'status -u -v' view,
> certainly a more expected behavior with '-v' included. The '-u'
> is the short-hand for '--show-updates', documented to 'add working
> revision and server out-of-date information', while '-v' is 'print extra
> information'. Both of these argumets trigger network access for
> command (which is otherwise a local operation), and display extra
> which is not stored in the WC (so must be retrieved from the server).
> the info in question (last committer) is only displayed when the info is
> retrieved from the server, it should correspond to the info that the
> knows about the versioned resource (rather than to what the WC knows,
> is out of date).
> Though '-u' also retrieves information from the server, it does not
> the user name of the last committer to a file, so I wouldn't
> expect the API equivalent of 'svn st -u' to fill in any such information
> the data structures it produces without '-v' also being included (I'd
> such fields to be NULL).

Perhaps the answer is to just modify the struct the way that Paul's patch
does and just address this within JavaHL? In other words, the JavaHL
Status class would not change to have the new fields. Instead, the
SVNClient.cpp native code would just populate the fields in that class the
way that I have described (when contactServer is true). Of course, we
could also potentially change the CLI when the -v option is specified to
use the new struct fields for the output, if it is agreed that it is

I still think the URL and node kind fields ought to just always be
populated. It seems like a waste of memory to duplicate them when they
will never be different. The issue for us in JavaHL is that when there is
a new file in the repository these fields are currently always null, and
we really need a value for those fields in that scenario.


Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Aug 23 22:55:42 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.