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.




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



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=markup 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?




Forest Handford, Supervisor Development, 781-774-5148
Medical Information Technology, Inc.
Mailstop: S4W186W, MEDITECH Circle, Westwood, MA 02090