On Wed, 1 Jun 2005, Philip Martin wrote:
> email@example.com writes:
> > Author: lundblad
> > Date: Wed Jun 1 15:47:41 2005
> > New Revision: 14921
> > Added:
> > trunk/subversion/clients/cmdline/dtd/status.dtd
> > Modified:
> > trunk/subversion/clients/cmdline/cl.h
> > trunk/subversion/clients/cmdline/main.c
> > trunk/subversion/clients/cmdline/status-cmd.c
> > trunk/subversion/clients/cmdline/status.c
> > trunk/subversion/tests/clients/cmdline/stat_tests.py
> > trunk/tools/client-side/bash_completion
> > Log:
> > Fix issue 2069 - "svn status" in xml mode.
> I'm not sure who or what is going to use xml mode, but it shows less
> information that plain status. The issue cites long user names
> containing spaces but the xml doesn't appear to include user names?
> The xml doesn't show revision numbers either, so it's impossible to
> distinguish single and mixed revision working copies. Is this just
both showing last committed info and WC revisions are possible
improvements. Alexander: want to work on these?
OTOH, if you actually read the DTD, you'll see that the XML mode shows
more information regarding out-of-date status and WC and repository locks.
> XML for the sake of it? Perhaps we should just have a non-xml mode
> that drops the username instead?
I don't know where you got that impression. Just because there is one
field missing that you want doesn't make it useless, does it? And leaving
out -v already avoids printing usernames. But if you *need* those
usernames that's not an option (or last committed date or something).
But what this and other patches adding --xml output wants to solve is that
we can't guarantee that our output will stay the same forever. We had to
make an incompatible change to the svn update output in 1.3, for example.
Fortunately, status had unused columns available this time, but that may
obviously not be the case in the future.
Also, this issue has been around for some time and the patch have
circulated six times on the mailing list. If you have objections to the
functionality - adding xml output to status - IMO it makes much more sense
to raise those objections earlier in the process than after the commit and
I'm actually getting a little annoyed by it. I'm not saying it's too late
to revert this work and if others dislike it, that will be done of course.
But it's not like this feature has been implemented invissibly in any way.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Thu Jun 2 09:31:49 2005