Peter N. Lundblad wrote:
> 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*.
But if you treat this as an error, then what would svn_client_status2()
return for this file? Time to introduce a new status enum field
'inconsistent EOLs'?
> > >> 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 for the clarification.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
---------------------------------------------------------------------
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:14:23 2006