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
and
> > > 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
fields
> > > (revision, date, and author). However, since changing those fields
would
> > > visibly change the output of status, I can see where some people
would
> > > 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,
but
> certainly a more expected behavior with '-v' included. The '-u'
argument
> 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
'status'
> command (which is otherwise a local operation), and display extra
information
> which is not stored in the WC (so must be retrieved from the server).
Because
> 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
server
> knows about the versioned resource (rather than to what the WC knows,
which
> is out of date).
>
> Though '-u' also retrieves information from the server, it does not
display
> the user name of the last committer to a file, so I wouldn't
necessarilly
> expect the API equivalent of 'svn st -u' to fill in any such information
in
> the data structures it produces without '-v' also being included (I'd
expect
> 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
desirable.
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.
Mark
_____________________________________________________________________________
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