On Tue, 23 Aug 2005, Mark Phippard wrote:
> Daniel Rall <email@example.com> wrote on 08/23/2005 04:47:55 PM:
> > 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.
Assuming a change along these lines is the appropriate way to go, why not
make it to the core SVN libraries rather than to just the JavaHL bindings?
Subclipse can't be the only GUI to find this information useful -- this does
not strike me as an isolated use case.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Fri Aug 26 00:46:18 2005