[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r19971 - trunk/subversion/libsvn_wc

From: Peter N. Lundblad <peter_at_famlundblad.se>
Date: 2006-06-13 22:06:55 CEST

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.