On Fri, Nov 5, 2010 at 7:07 AM, Jochen Stiepel <j.stiepel_at_gmail.com> wrote:
> I'm using subclipse 1.6.15 with JavaHL SVN 1.6.13, Java 1.6.21, German
> Windows XP.
> If I checkout a file with subclipse the date is formatted in this way:
> * @version $Revision: 2 $ $Date: 2010-07-13 00:58:18 +0200 (Di, 13 Jul 2010) $
> If I checkout the same file with svn (commandline) there is a "."
> (dot) after the 13:
> * @version $Revision: 2 $ $Date: 2010-07-13 00:58:18 +0200 (Di, 13. Jul 2010) $
> ^ this dot
> Does anyone know why there is a difference in the format between
> subclipse and "normal" svn ?
> This dot makes it more compilcated to compare the file with eclipse/compare.
If you are using JavaHL, then Subclipse is "normal" SVN. Subclipse
does not read/write or otherwise touch any files in the working copy.
It is all done by SVN. JavaHL is the Java interface they provide to
the same libraries used by the command line.
Based on the content of the date in the expansion SVN obviously
accesses some kind of LOCALE to determine the format to use in the
expansion. Maybe the setting is subtly different in your command line
session and the Eclipse environment?
Which compare option are you using? The Subversion diff routine is
smart enough to ignore the keywords so we try to use it as much as
possible to get a list of what files changed before feeding them to
the Eclipse GUI. Eclipse will still show keywords as differences, but
we at least avoid Eclipse showing files where that is the only
difference. This is only applies in the scenarios where we can use
svn diff in front of the Eclipse compare process. Unfortunately, the
Eclipse GUI does not let us feed it the diff output to render, just
the list of files (and it then does its own diff again).
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subclipse.tigris.org].
Received on 2010-11-05 12:34:33 CET