Stefan Küng writes:
> Garrett Rooney wrote:
> [snip]
> If the error SVN_ERR_IO_INCONSISTENT_EOL is returned only if there are
> no other changes, we could just mark the file as unmodified and ignore
> the error. But if the error is returned as soon as inconsistend EOLs are
> found without checking the whole file for modifications, then that's not
> an option.
>
The latter is actually the case. I see no reason to treat this condition
as an error *here*.
> >> In 1.3.x, inconsistent EOL fail in the commit, but in a later state
> >> then the check for modifications state. I'm sceptical to why this is
> >> useful, but maybe it catches some user error or something?
> >
> > Well, we could just put it back the way it was, repairing the eols. I
> > have no strong objection to that, I just assumed that when it was
> > changed to not do so there was a reason for it...
>
> Checking the status should never modify a file. At least that was a
> consensus a long time ago (with the discussion about 'fixing' file
> timestamps with 'svn st' so that unmodified files don't have to be
> checked fully every time).
> I think it should stay that way ('svn st' *not* modifying/fixing the
> file contents).
>
I think no one is proposing that status should actually change the contents.
"Repair" above, only means that the stream that reads the file will ignore
the inconsistencies.
Thanks,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jun 13 22:10:22 2006