subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bert Huijben" <b...@qqmail.nl>
Subject RE: SVN Status Command Line in 1.8 vs 1.7
Date Wed, 05 Mar 2014 14:59:34 GMT
                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@meditech.com] 
Sent: woensdag 5 maart 2014 15:40
To: users@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 


Mime
View raw message