On 2009-08-05 11:35:17 -0500, Peter Samuelson wrote: > > [Vincent Lefevre] > > In fact, canonicalizing the $Id$ keyword would not be the correct > > solution, because when the Id keyword is removed, one should get > > the orignal data back (instead of $Id$), here > > > > $Id: lplain.bst,v 4.0 2000/01/31 18:11:53 vlefevre Exp $ > > I don't agree. I think you should get back $Id$, because that's what > the repository was _supposed_ to have in it all along. Somehow it did > not have that, due to some other bug, but the solution is to compensate > for the other bug, not to compound it.
The problem is the following: the repository/dump has 1. a file whose contents look like an expanded keyword (but really isn't -- anyway expanded keywords are only in working copies): $Id: lplain.bst,v 4.0 2000/01/31 18:11:53 vlefevre Exp $ 2. on this file, a svn:keyword property containing Id. from r1950 to r1952. If Subversion doesn't regard $Id: ... $ as equivalent to $Id$ in such cases, then this makes a contradiction, until there's a revision where (1) or (2) has disappeared (r1953 in my case, where I removed the svn:keyword property). You're saying that the repository was supposed to have (2) only (i.e. a svn:keyword property containing Id, and $Id$ in the text contents of the repository). I'm saying that the repository was supposed to have (1) only (i.e. the string that looks like an expanded keyword, but no such keyword). Indeed the Subversion bug was that I removed a svn:keyword property in r1950, but Subversion didn't do the removal completely (it didn't remove the property, while assuming that the property was removed so that $Id: ... $ wasn't compressed to $Id$ in the text contents). If you consider that the file should contain $Id$, then this would break the contents from r1953 and all later revisions. -- Vincent Lefèvre <vinc...@vinc17.org> - Web: <http://www.vinc17.org/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/> Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
