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

End of the Line for Merge? [Merging and EOL Style Problem]

From: Rob Hubbard <Rob.Hubbard_at_celoxica.com>
Date: 2006-08-15 14:39:29 CEST

Hello,

This is a question about merging and end of line styles.

Some time ago, we replaced VSS with SVN. When I set up the repository, I spent quite some time trying to get things right first time. There was at least one thing I missed...

The problem is as follows.

The repository contains at least two active development branches of a project. The sources are used to build the product on both Linux and Windows. The members of the team use different editors, and those editors cope with different line endings in different ways.

The result is that the repository, from time to time contains source files with a mixture of end-of-line styles (usually CR+LF sprinkled with a few instances of LF only). This is troublesome because different programs count lines in different ways, and in particular, debuggers can end up showing you the wrong line.

Now, what I would like to do is to set the svn:eol-style on all the source files (to either "LF" or "native"; to be decided). Such action seems result in SVN taking care of inconsistent line endings in the repository upon svn commit.

There is an obstacle to just going ahead and doing this. When svn:eol-style is changed (certainly to "LF" or "native"), SVN appears to store these internally as an LF. Our files are mostly Windows-style CR+LF. Therefore, when the property is set, every, or nearly every, line of those files will change. A minor problem is that that will effectively hide the history up to that point of all lines when doing an svn blame. A more serious problem is that svn merge will now fail properly to synchronise the two/three files, even if the svn:eol-style change has been performed on both branches concerned.

One solution requires a time machine: to set the svn:eol-style property on all files from the first revision. Is there a way that this could be 'hacked'? For example, I wondered whether this might be possible via a dump-load cycle (e.g. using a script to edit the dump file for the svn:eol-style property at each instance of an added text/source file).

Alternatively, if the svn:eol-style properties are set on all active branches from the current revision, is there a way to deal better with merge/update - that is to merge (perhaps through a third-party merge program) but for merge to ignore line-ending changes?

Obviously, I also need to set up everyone's config file with the appropriate autoprops, and perhaps write a server-side script to check the properties of added files, to avoid similar problems in future. (I gather that server-side autoprops are being considered.)

[Another solution would be for a server-side script to check for consistent line endings during a commit; but I'd rather use the svn:eol-style mechanism.]

Many thanks in advance,

Rob.

_____________________________________________________________________
This message has been checked for all known viruses by the MessageLabs Virus Scanning Service, on behalf of Celoxica Ltd.

This email and any files transmitted with it are confidential and
may be legally privileged. It is intended solely for the use of the
individual or entity to whom it is addressed. If you have received
this in error, please contact the sender and delete the material
immediately. Whilst this email has been swept for viruses, you
should carry out your own virus check before opening any
attachment. Celoxica Ltd accepts no liability for any loss or
damage which may be caused by software viruses or interception
or interruption of this email.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Aug 15 14:40:48 2006

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.