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

RE: SVN Status Command Line in 1.8 vs 1.7

From: Bert Huijben <bert_at_qqmail.nl>
Date: Wed, 5 Mar 2014 15:59:34 +0100

                Hi,

 

As far as I know the last time we updated the columns for 'svn status' was
with Subversion 1.6 when we introduced tree conflicts. But while we do
promise 'svn status' output stability within minor releases we don't promise
that over minor releases.

 

As project we would recommend processing the xml text output (--xml) if you
want to keep things stable for future releases.

 

Another option would be to use one of the many language bindings to access
the Subversion api directly. There are bindings for Java (JavaHL, SvnKit),
C#/.Net (SharpSvn) various swig wrappers.

 

                Bert

 

From: Forest Handford [mailto:fhandford_at_meditech.com]
Sent: woensdag 5 maart 2014 15:40
To: users_at_subversion.apache.org
Cc: David T. Murphy; SVN Users
Subject: SVN Status Command Line in 1.8 vs 1.7

 

A colleague of mine and I discovered that the location of the working
revision (working_rev) in 1.8.3 is different from 1.7.12 . We are both
using svn.exe from the TortoiseSVN package on Windows. In 1.7 he gets the
following:

 

M 1167395 1164911 FHANDFORD
C:\ProgramData\Meditech\MTCM.Universe\MTCM.DEVF.Ring\!AllUsers\Sys\PgmCache\
Ring\PgmSource\Foc\FocZ.Subversion.C.focus

 

In 1.8 I get:

 

M 1167395 1164911 FHANDFORD FocZ.Subversion.C.focus

 

C:\ProgramData\MEDITECH\MTCM.Universe\MTCM.DEVF.Ring\!AllUsers\Sys\PgmCache\
Ring

Notice how in 1.8 working_rev is one character further left. I took a peak
at
http://svn.apache.org/viewvc/subversion/trunk/subversion/svn/status.c?view=m
arkup in various revisions since march 2013. The svn_cmdline_printf() call
in print_status() appears to be consistent. working_rev also seems to be
consistently set using apr_psprintf(pool, "%ld", status->revision). We can
parse it correctly with either position, but worry that the position may
arbitrarily change in the future causing future parsing to fail. As an
example, if it moved yet another space to the left, we would lose the left
most digit. Any ideas?

 

Thanks,

Forest

-- 
Forest Handford, Supervisor Development, 781-774-5148
Medical Information Technology, Inc.
Mailstop: S4W186W, MEDITECH Circle, Westwood, MA 02090 
Received on 2014-03-05 16:00:14 CET

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

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