On Apr 6, 2009, at 16:38, Thornock, Brian (Brian) wrote:
> The "svn diff" command seems to be inconsistent across various
> files in my Java repository.
> I imported several java files from ClearCase into a Subversion
> repository. The "eol-style" property is set to "native".
>
> For me to reproduce, I test with 2 files in the same package and
> directory:
> *I checkout the repository: svn co http://svn/repos/trunk ./code-
> devel
> *svn diff TestClient.java = reports no change
> *Open TestClient.java in VI, add a single line in the header
> comment section
> *svn diff TestClient.java = shows the diff with the 1 extra line
>
> *svn diff TestConnector.java = reports no change
> *Open TestConnector.java in VI, add a single line in the header
> comment section
> *svn diff TestConnector.java = reports every line changed
>
> There are about 20 files scattered throughout our base in various
> packages that have this weird problem where once you change
> something in the file, every line says it's modified. Even if I
> delete the line, it still reports every line as modified; I have to
> svn revert these 20 files. All the other files behave as expected.
This could be due to an import tool that didn't normalize your files'
line endings.
I assume you used some automated script to import your repository
from ClearCase into Subversion? And during the import, it added
svn:eol-style properties to your files? At that time, it was also the
import script's responsibility to convert the line endings actually
present in those files to LF (yes, LF, irrespective of what value you
set the svn:eol-style property to). If the import script did not do
this, then you have files in your repository that Subversion *thinks*
have LF line endings, but which actually have some other line
endings. When it comes time for it to compute a diff, it sees every
line as changed due to the differing line endings.
If you can afford to dump and load your repository and change its
UUID, and thereby invalidate everyone's working copy and require them
to check out new ones, then you may want to do so and give
svndumptool a go. It has a feature for fixing line endings. You would
"svnadmin dump" your repository, run "svndumptool.py eolfix" to fix
the line endings in the dumpfile, then "svnadmin load --ignore-uuid"
the fixed dumpfile into a new repository you've "svnadmin create"d.
Be sure to use the "--ignore-uuid" switch to "svnadmin load" so that
a new UUID is generated; since this new repository's contents is not
identical to the old one's, you must use a new UUID.
http://svn.borg.ch/svndumptool/
Note: of course you can test this conversion without impacting the
users of your repository, so if I'm wrong about the cause it doesn't
mean any downtime for anyone.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1568527
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-04-07 03:13:12 CEST