On Tue, Feb 23, 2010 at 08:57:26PM +0100, Daniel Näslund wrote:
> On Tue, Feb 02, 2010 at 09:11:52PM +0100, Stefan Sperling wrote:
> > On Tue, Feb 02, 2010 at 08:48:43PM +0100, Daniel Näslund wrote:
> > > Hi Stefan!
> > >
> > > In match_hunk() we try to match lines from the context of the patch with
> > > lines in the target. Earlier, in init_patch_target() we detect the eol
> > > of the target and open streams to read from the target and to write the
> > > patched result. Those streams does translation of keywords and eols.
> > >
> > > In match_hunk we read a line from original_text and translate it. But we
> > > don't get any translation of the eols in hunk_line_translated.
> >
> > svn patch only repairs EOLs if the svn:eol-style enforces a fixed
> > value (such as CR or CRLF). Try setting svn:eol-style to 'CRLF' on
> > the patch target. Then you'll see dos-style newlines in the patched result.
> >
> > Admittedly, we may want to repair EOLs in more scenarios (such as
> > eol-style = native).
>
> I have a test where the target uses '\r\n' and the patch uses '\r' . The
> eols are consistent within each file but we get a failure saying:
>
> [[[
> subversion/svn/patch-cmd.c:81: (apr_err=135000)
> subversion/libsvn_client/patch.c:1463: (apr_err=135000)
> subversion/libsvn_client/patch.c:1410: (apr_err=135000)
> subversion/libsvn_client/patch.c:1100: (apr_err=135000)
> subversion/libsvn_client/patch.c:830: (apr_err=135000)
> subversion/libsvn_client/patch.c:799: (apr_err=135000)
> subversion/libsvn_subr/subst.c:876: (apr_err=135000)
> subversion/libsvn_subr/subst.c:643: (apr_err=135000)
> svn: Inconsistent line ending style
> ]]]
Where and how?
> What to do?
> [ ] Write documentation saying we can only repair eols on targets with a
> svn:eol-style prop.
That's my plan. Don't try to repair if no svn:eol-style is set.
> [ ] Wrap the error for a better error message perhaps saying 'patch and
> target uses different eol' or similar.
> [ ] Adjust the code to allow for repairing eols even when there is no
> svn:eol-style prop. I would go for this one if it's doable.
>
> Before I throw myself to the mercy of the eol-translating code, I ask
> you if there is something you know of hindering us from repairing eols
> where there is no prop set?
The property is the only way for the user to tell us what the EOL
style of the file should be. If the property isn't set, we simply
don't know what the user wants. Then, if the patch and target are
a mixed bag of EOLs, we should go for a best-effort approach.
Let's just say that in case of ambiguity, the target wins.
Else the patch wins.
For example, assuming mixed eol styles in both patch and target,
and no fixed EOL-style on the target:
Original line in patch says '\n', target says '\r'
If modified line in patch changes to '\r': use '\r'
If modified line in patch says at '\n': use '\r'
Original line in patch says '\n', target says '\n'
If modified line in patch changes to '\r': use '\r'
If modified line in patch says at '\n': use '\n'
This second example makes patches which change only line endings work.
Note that this is per *line*, not per hunk. We make those
decisions on a per-line basis. There are 3 supported EOL styles
so the above examples need to be generalised.
> * We falsely label targets with inconsistent eols to be of type
> eol_style_fixed. But after patching the eols will be consistent and
> that's a good thing.
But what if people really want files with mixed EOLs?
> * [Placeholder for more stuff that can go wrong]
>
> Or we could set the style to svn_subst_eol_style_native. We will end up
> with native newlines in the target then, right?
If the target has svn:eol-style 'native', it will have a consistent
EOL-style, unless the file has been messed with. But if it has been
messed with, writing data through the translation stream will normalise
newlines again. So the patching process will repair broken EOLs in this
case.
Stefan
Received on 2010-02-23 21:32:00 CET