Julian Foad <julianfoad@btopenworld.com> writes:
> Oops. I had first read your reply as "I think refusing to repair
> the line endings is fine", and therefore thought you were saying you
> would be happy for me to modify it, and so I did. I'm sorry. I was
> just replying to this mail when I read your words and noticed my
> misunderstanding. Grrr. Now what?
>
> Why do you think repairing the line endings is fine? It is
> inconsistent with "commit". Do you think commit should repair them
> too, or do you think it is right for them to behave differently?
It is perfectly okay for them to behave differently, in my opinion.
In fact, it is perfectly okay for commit itself to behave differently
depending on what's being committed -- we could make commits of "adds"
do repairs (which would be consistent with import), but not commits of
modifications to already-versioned things -- as long as we have a
legitimate reasonings for our behavior.
I have two main reasons for why I think it could be okay for import to
behave differently than commit:
(1) Auto-props are something each user turns on for him or herself.
So if you go through the effort of enabling those badboys, an
import that goes awry eol-style-wise can reasonably be
considered the user's own fault.
Commits of already-versioned files, however, don't advertise
that they have an eol-style setting. Some other user might have
set that property on the files, and the committing user could be
completely unaware of this fact. An automatic repair might
actually damage purposefully-inconsistent line endings, and the
committing user won't know what hit him.
(2) Import never touches the original file. So if something goes
wrong with the import, you still have your original data. IIRC,
Commit, on the other hand, actually replaces the working file
with a de-and-re-translated file upon completion of the commit.
So if it repaired something it wasn't supposed to, you'd have to
retrace your steps to correct the problem.
All of that said, I don't have strong opinions about the matter. I
think the majority of the use cases which are interesting to this
discussion could be considered edge cases in the grand scheme of things.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Mar 9 19:00:15 2004