On 6/7/06, Peter N. Lundblad <peter@famlundblad.se> wrote:
> rooneg@tigris.org writes:
> > Modified: trunk/subversion/libsvn_wc/questions.c
> > URL: http://svn.collab.net/viewvc/svn/trunk/subversion/libsvn_wc/questions.c?pathrev=19971&r1=19970&r2=19971
> > ==============================================================================
> > --- trunk/subversion/libsvn_wc/questions.c (original)
> > +++ trunk/subversion/libsvn_wc/questions.c Tue Jun 6 12:48:38 2006
> > @@ -273,6 +273,7 @@
> > apr_file_t *v_file_h, *b_file_h;
> > svn_stream_t *v_stream, *b_stream;
> > const svn_wc_entry_t *entry;
> > + svn_error_t *err;
> >
> > SVN_ERR(svn_io_file_open(&b_file_h, base_file, APR_READ,
> > APR_OS_DEFAULT, pool));
> > @@ -321,8 +322,15 @@
> > }
> > }
> >
> > - SVN_ERR(svn_stream_contents_same(&same, b_stream, v_stream, pool));
> > -
> > + err = svn_stream_contents_same(&same, b_stream, v_stream, pool);
> > + if (err && err->apr_err == SVN_ERR_IO_INCONSISTENT_EOL)
> > + {
> > + same = FALSE;
> > + svn_error_clear(err);
> > + }
> > + else if (err)
> > + return err;
> > +
>
> 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?
> 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....
-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:05:40 2006