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

Re: Migrating repository from Windows to UNIX and eol-style

From: Joe <dev_at_freedomcircle.net>
Date: 2006-06-29 03:03:13 CEST

Andy Levy wrote:
> If you want to do a mass conversion, you can, and it'll be only a
> property change, there won't be any delta on the file contents
> themselves.

OK, I ran a small test on a subtree of one of the repositories. I
checked out the files, did a propset svn:eol-style native on all of them
and then checked them in. Now the svnadmin dump output (for the files
in last revision) is clear of CRs, so it should load nicely into BSD.

However, after the change is committed, any diff between files before
and after the propset shows as the entire old file followed by the new
file, and svn blame reflects every line as the latest, post-propset
revision. That would also affect any attempt to merge changes from any
branches before and after the propsets.

Pragmatically, I guess there's not much that I can do except bite the
bullet and apply the propsets (although I must admit I'm tempted to
fiddle with the svnadmin dump output--like what happens in the load if
Text-content-md5: is missing or incorrect?).

Philosophically, I think the enable-auto-props parameter, at a minimum,
deserves highlighting in the docs, particularly for Windows
administrators. Ideally, I think the eol-style property should be
reconsidered as a server-side parameter. Just as svn uses a "very basic
heuristic to determine if [a] file consists of human-readable or
non-human-readable content", it makes sense that if it's human-readable,
eol-style should be assumed to be native (unless proven otherwise).

Joe

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jun 29 03:03:37 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.