On 6/7/06, Peter N. Lundblad <peter@famlundblad.se> wrote:
> 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.
Hmm. That's a good point...
> > > 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?
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...
-garrett
---------------------------------------------------------------------
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:37:22 2006