On Jun 29, 2006, at 03:03, Joe wrote:
> 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.
Again, there should be no connection between the svn:eol-style
property of your files and the fact that you want to dump and load
the repository. In particular, I'm having trouble with your last
sentence. You seem to be under the impression that the presence of
CRs in the dumpfile would prevent it from loading on a Subversion
server running on BSD. But that should not be the case; there should
be no problem loading the dumpfile, on BSD or any other OS.
> 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
Yes, those full-file diffs are inconvenient, and complicate merging,
so it would be best to inform all developers that they should commit
all changes before you do the mass propset, and encourage everyone to
do an update immediately after before starting on new work.
> (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?).
I don't think that's a good idea. Your repository is supposed to
represent historical data, and you're proposing to rewrite history.
What if something breaks because of this change? What if you've
inadvertently programmed in a dependency on DOS linefeeds at some
point in your application, and your app now breaks due to this
conversion? You wouldn't be able to go back in the repository to the
last version where you know it worked to compare the changes. All
your old versions would be broken too.
> Philosophically, I think the enable-auto-props parameter, at a
> minimum, deserves highlighting in the docs, particularly for
> Windows administrators.
I don't see why this problem is any more acute for Windows users vs.
users of any other OS.
As you know, auto-props are described in the book. Was there some
part of that section that was unclear? Or do you feel it should have
been mentioned earlier in the book? Version control is a complicated
topic, which is why there's a big book describing it, and not
everything can be taught at once. You really have to start with the
basics and then introduce additional concepts as you go along. Auto-
props is not central to the function of what Subversion does, which
is probably why it's not mentioned in chapter 1. But if you have
suggestions for how the book can be improved, I believe they have
their own mailing list.
> 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).
That quote is from the auto-props page [2] in the book. It would be
interesting to know where this decision is made -- in the client
before sending the data to the server, or on the server once the data
arrives. I suspect it's in the client, since the behavior would also
have to occur for file:///-based repositories where no server process
exist. Thing is, I don't believe Subversion has any kind of server-
side parameters such as you desire.
Furthermore, I disagree that svn:eol-style should be automatically
assumed on anything. I think it's better for Subversion to assume
that it should do nothing unless you tell it to, as is the case now.
What if, again as above, I have a data file that has DOS linefeeds,
and I program a script to read this file and my programming assumes
DOS linefeeds? (I'm sure there are several scripts like this in our
company's repository right now.) I would test it locally on my Mac,
it works great, and I commit it and go home for the day. Tomorrow
someone updates their working copy on their Linux machine, only that
DOS data file I committed has been converted to Unix linefeeds and my
script doesn't work anymore. I'd get flak for committing something
that didn't work, only it did work before I committed it. That's no
good.
[1] http://svn.collab.net/repos/svn/trunk/notes/skip-deltas
[2] http://svnbook.red-bean.com/en/1.2/
svn.advanced.props.html#svn.advanced.props.auto
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jun 29 14:05:25 2006