You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Rob Hubbard <Ro...@celoxica.com> on 2006/08/15 12:39:29 UTC

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

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


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

Posted by Nico Kadel-Garcia <nk...@comcast.net>.
Rob Hubbard wrote:

> 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.

This is an old bane of source control systems, whether you use native EOL or 
not. Fixing it is often a multi-step process.

1: Work out a way to force svn:eol-style going forward. You don't want this 
happening again.
2: Convert every appropriate file as determined by those new policies that 
should have an svn:eol-style set.
3: Use dos2unix or unix2dos or a tool like that to convert every file.
4: Commit them as changed.
5: Set every darned file to the new style.
6: Commit that.

You'll run into trouble with anyone who expects to use an NFS or SMB mounted 
directory to use the same codebase for both Windows and UNIX-like systems, 
or MacOS. Make people check out local copies instead of sharing. Also, make 
sure that CygWin installations use *WINDOWS* end-of-line style, not UNIX 
end-of-line style, or any use of Subversion from inside CygWin will 
seriously muck up local copies.

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

dos2unix and unix2dos are built into most UNIX-like systems and CygWiin 
these days.

> 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.]

You really, really, really want that pre-commit going forward. Honest. 

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org