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

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

From: Rob Hubbard <Rob.Hubbard_at_celoxica.com>
Date: 2006-08-15 17:03:51 CEST

Hello,

Thanks for the reply Nico.

> 1: Work out a way to force svn:eol-style going forward. You don't want this
happening again.

Well, I suppose that pre-commit could check all added files for either the presence of a valid svn:eol-style property or explicit membership of a list of permitted exclusions (such as *.gif files).

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

What's reason for using this many separate steps please?

I'd assumed I could simply set the svn:eol-style on all appropriate files and commit; I think SVN itself modifies the files (in the repository, at least) on the commit. Or am I mistaken? (My working copy might need a "downdate"/update-cycle to deal with the working copies of files, perhaps.)

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

Yes; for badly conflicting files, dos2unix could be applied to the triple of input files SVN produces (*.mine etc.) and then diff3 or diff/patch could be applied again manually. Hopefully that would result in smaller, more localised conflicts, rather than whole-left-file/whole-right-file conflicts.

Is there any way to get SVN to use programs like diff and patch with end-of-line-insensitive processing in the first place, rather than dealing with poor merge results afterwards?

(I recently posted another query relating to that: <http://svn.haxx.se/users/archive-2006-08/0643.shtml>.)

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

Okay. Yes, that would protect against users not having their autoprops set correctly.

Thanks again,
Rob.

-----Original Message-----
From: Nico Kadel-Garcia [snip]
Sent: 15 August 2006 14:15
To: Rob Hubbard; users@subversion.tigris.org
Subject: Re: End of the Line for Merge? [Merging and EOL Style Problem]

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.

_____________________________________________________________________
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 17:05:18 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.