Garrett Rooney writes:
> On 6/7/06, Peter N. Lundblad <peter@famlundblad.se> wrote:
> > I feel uneasy about this change. Why should a file always be treated as
> > modified just because it has inconsistent end of line markers? Why
> > can't we just set always_repair to TRUE here? My reasoning is that if
> > eol style is set, then the file will/should be normalized in the
> > repository.
>
> Well, if it's been normalized in the repository, then any
> inconsistency here implies that it's been changed since then, right?
But if the only change was to replace CRLF with LF, that will not be visible
in the commit, since the newlines will be normalized. This is the same
as manually modifying some keyword values.
> > For example, if I have an svn:eol-style='native' file and
> > change the eol markers to CRLF (which isn't the native format on my
> > system) svn st still shows the file as unmodified.
>
> Umm, as I read the code, shouldn't tihs make it so that if you change
> to CRLF it'll show up as modified, since that'll result in an
> inconsistent EOL error, which sets same to FALSE....
>
Only if the eols are truly inconsistent in the file. If I change all
eol characters to another eol style, the file shows up as unmodified.
When I try this with 1.3.x, it does say unmodified. I think 1.4.x
should do the same. Also, I don't think text_modified_p should check
for inconsistent eol styles at all, but I think it is better to repair
the file on conversion than ignoring the error.
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?
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jun 7 14:34:40 2006