[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: Garrett Rooney <rooneg_at_electricjellyfish.net>
Date: 2006-06-07 14:36:35 CEST

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...


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

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