bug-texinfo
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: XeTeX encoding problem


From: Karl Berry
Subject: Re: XeTeX encoding problem
Date: Mon, 28 Mar 2016 23:29:49 GMT

Regarding \pdfgettoks and texinfo.tex, I temporarily enabled CVS in
texinfo on Savannah and did the "annotate" there.  Result attached for
posterity.  The \pdfgettoks line was there in version 1.1, and never
changed.  So it predates (use of) CVS.  If we ever need to, looking at
old releases would presumably narrow down when it was added, since it
was definitely not there from the beginning (PDF didn't exist yet).
(Could also ask Thanh and Hans Hagen if they have any memories/archives
of it.)

    svn blame --force does it, 

Ah, good.

    but it shouldn't be a binary file in the
    first place.

Looking into this a little, it seems that if the file was ever treated
as binary, an svn blame including that revision will fail.  Not
surprisingly.  And since svn treats all files as binary by default,
the original cvs-to-svn conversion I did may have started everything as
binary.  And/or whenever anyone without auto-props set makes a commit.

http://svn.haxx.se/users/archive-2008-10/0270.shtml
http://stackoverflow.com/questions/15300574/proper-mime-type-of-shell-scripts-in-subversion
http://subversion.1072662.n5.nabble.com/svn-blame-not-working-for-files-which-had-binary-mime-type-in-a-previous-revision-td177847.html

I couldn't find a recipe for a repository administrator (= me, in this
case) to eradicate the binary-ness of all revisions in the repository.
But since we have --force, doesn't seem important enough to pursue to
the bitter end.

Thanks,
Karl

Attachment: texinfotex-cvs-annotate.html.gz
Description: Binary data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]