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