Re: Issue #1756 -- import doesn't handle svn:eol-style or svn:keywords

C. Michael Pilato wrote:
>
> 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.

OK.

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

OK if our behaviour is documented. (Presently, it isn't in the book: the section on svn:eol-style doesn't mention consistency, and auto-props aren't mentioned at all.)

> (2) Import never touches the original file. So if something goes
> wrong with the import, you still have your original data. IIRC,
[...]

Good point.

Thank you for explaining your thoughts. I accept your reasoning that it could be OK for Subversion to repair line endings in some situations and complain in others, if we wanted that. I had not thought of those arguments. Yet, as fas as I know, we still have no reason to want that difference, so we should keep things simple by having the same behaviour in all cases. If the documentation can be simple and yet accurate, that tends to be a good sign.

> All of that said, I don't have strong opinions about the matter. I

For the record, I am interpreting this as meaning that you do not object to r8950 (which causes inconsistencies to be rejected).

> think the majority of the use cases which are interesting to this
> discussion could be considered edge cases in the grand scheme of things.

Indeed they could. Still, the fewer edge case surprises we have, the better.

- Julian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Mar 9 21:56:05 2004