Re: "svn patch" and the TAB character
On Fri, Dec 13, 2019 at 5:00 PM Doug Robinson wrote: > If I use "svn diff --patch compatible" to produce a patch file. Then edit > that patch file using an editor with settings that replace the TAB with a > "proper" number of SPACE characters, the "svn patch" command will declare: > > $ svn patch ../n.txt > Skipped missing target: 'TheFile (revision 18)' > Summary of conflicts: > FWIW I did see this recently when trying to run a reproduction script from the TortoiseSVN forum. I realized that the tabs became spaced, fixed it, and then the patch worked. I don't have an opinion whether this behavior should be changed or not, but perhaps we can try to detect this case and improve the error message? Nathan
Re: Translatable diff headers (was: Re: "svn patch" and the TAB character)
On Sat, Dec 14, 2019 at 12:28:04PM +, Daniel Shahaf wrote:
> Stefan Sperling wrote on Sat, 14 Dec 2019 11:13 +00:00:
> > The problem is that svn diff's revision number marker " (revision XY)" must
> > be separated by a TAB.
>
> In diff generation, the whole string is translated: _("%s\t(revision
> %ld)"). It seems to me that if a translator changed the start of the
> string from "%s\t" to anything else, patches would no longer apply,
> would they? If so, shouldn't we make just the "(revision %ld)" part
> translatable?
>
Yes, that would be better indeed.
Translatable diff headers (was: Re: "svn patch" and the TAB character)
Stefan Sperling wrote on Sat, 14 Dec 2019 11:13 +00:00:
> The problem is that svn diff's revision number marker " (revision XY)" must
> be separated by a TAB.
In diff generation, the whole string is translated: _("%s\t(revision
%ld)"). It seems to me that if a translator changed the start of the
string from "%s\t" to anything else, patches would no longer apply,
would they? If so, shouldn't we make just the "(revision %ld)" part
translatable?
Re: "svn patch" and the TAB character
On Sat, Dec 14, 2019 at 10:59:01AM +, Daniel Shahaf wrote: > Doug Robinson wrote on Fri, 13 Dec 2019 21:59 +00:00: > > If I [...] edit that patch file using an editor with settings that replace > > the TAB > > with a "proper" number of SPACE characters, > > Don't do that. If the context lines start with tabs (ignoring the first > column), they would be corrupted and the patch wouldn't apply — and even > if it did apply, the indentation would be off-by-one or off-by-eight. > However: > > > $ svn patch ../n.txt > > Skipped missing target: 'TheFile (revision 18)' > > Summary of conflicts: > > Skipped paths: 1 > > > > (the TAB was between "TheFile" and "(revision...)". > > Fixing this specific case would be helpful to projects that use spaces- > only indentation where the unidiff got tabs-to-spaces'ed at some point > (e.g., some terminal emulators do this). I'm not opposed to it, though > I don't think it's high priority either. Does anyone have an algorithm > to propose? (An algorithm for deriving the name of a file to patch from > the +++, ---, and "Index:" lines.) > > Cheers, > > Daniel 'svn patch' already behaves like regular patch, i.e. it assumes the whole line denotes a file name if no TAB can be found. The problem is that svn diff's revision number marker " (revision XY)" must be separated by a TAB. Otherwise it becomes part of the file name. Perhaps --patch-compatible should omit those markers?
Re: swig-py3 str/bytes difference in svn_config_*()
Yasuhito FUTATSUKI wrote on Sat, 14 Dec 2019 04:19 +00:00:
> Though this issue was already resolved...
>
> On 2019/12/13 17:28, Yasuhito FUTATSUKI wrote:
> > On 2019/12/13 16:24, Daniel Shahaf wrote:
> >> Thanks for the quick fix. However, it doesn't work on my machine (Debian
> >> stretch).
> >>
> >> With your latest patch, «svn_config_get_user_config_path(None, None)»
> >> calls the C function of the name with «path == NULL» and segfaults
> >> immediately,
> >> because the parameter is dereferenced on the first line of the function.
> >> As to
> >> the other case, I get a bogus stack trace:
> >>
> >> [[[
> >> % PYTHONPATH=… lldb -- python3 -c $'from svn.core import *;
> >> svn_config_ensure("/tmp/foo")'
> >> (lldb) r
> >> Process 19706 launched: '/usr/bin/python3' (x86_64)
> >> Process 19706 stopped
> >> * thread #1, name = 'python3', stop reason = signal SIGSEGV: invalid
> >> address (fault address: 0x0)
> >> frame #0: 0x
> >> error: memory read failed for 0x0
> >> (lldb)
> >> ]]]
> >
> > Thank you for testing. I also tested and same result on FreeBSD
> > with Python 3.6. It seems "z*" format in PyArg_ParseTuple() doesn't
> > work I expected.
>
> That was my misreading of the spec[1][2]. The argment type for "z*"
> should be Py_buffer, not const char *. Similarly, "z#" can convert
> str(unicode), bytes, None into "const char *" and int, but it is not
> what we want here. Anyway we had to write additional code if we want to
> use parse=... feature of SWIG typemap here.
>
> https://docs.python.org/2.7/c-api/arg.html
> https://docs.python.org/3/c-api/arg.html
Thanks for following up; I looked up the same page yesterday but
overlooked the C types corresponding to each format code.
Cheers,
Daniel
Re: "svn patch" and the TAB character
Doug Robinson wrote on Fri, 13 Dec 2019 21:59 +00:00: > If I [...] edit that patch file using an editor with settings that replace > the TAB > with a "proper" number of SPACE characters, Don't do that. If the context lines start with tabs (ignoring the first column), they would be corrupted and the patch wouldn't apply — and even if it did apply, the indentation would be off-by-one or off-by-eight. However: > $ svn patch ../n.txt > Skipped missing target: 'TheFile (revision 18)' > Summary of conflicts: > Skipped paths: 1 > > (the TAB was between "TheFile" and "(revision...)". Fixing this specific case would be helpful to projects that use spaces- only indentation where the unidiff got tabs-to-spaces'ed at some point (e.g., some terminal emulators do this). I'm not opposed to it, though I don't think it's high priority either. Does anyone have an algorithm to propose? (An algorithm for deriving the name of a file to patch from the +++, ---, and "Index:" lines.) Cheers, Daniel
