Darren Chamberlain wrote: > Which API version do you mean? There's not really any variation in > the main SQL::Translator API, although individual modules have > different API "versions", e.g., arguments supported in later versions > of a parser but not an earlier one, but I can't imagine a good way to > genericize that across all the modules. Unless you mean have a $API > for *each* parser and producer? That seems like a nightmare to > maintain, especially since it would have to be maintained by hand. > > Or, we could version the API across the entirety of the codebase, > where a change in the Pg parser bumps the API number for everything. > In this case, we should just use $Revision$, and be sure to run `svn > update` before every release to ensure that $Revision$ for updated on > each file (I think svn update does that, right?). >
Castaway pointed me towards this thread that I apparently mass-read* To complement my explanation to the changes earlier today: you can use $Revision$ in the way you propose, because svn substitutes it with the revision where the file changed, not to which it is updated (second number of `svn status -v`). However I need to warn against using the automated substitution tools, because it breaks patch (the utility) in a subtle way. Consider a diff sent to you over irc/pastebin (just an example, it will become apparent why I chose this one below): Index: Parser.pm =================================================================== --- Parser.pm (revision 1439) +++ Parser.pm (revision 1440) @@ -3,7 +3,7 @@ # ---------------------------------------------------------------------- # $Id$ # ---------------------------------------------------------------------- -# Copyright (C) 2002-4 SQLFairy Authors +# Copyright (C) 2002-2009 SQLFairy Authors # # This program is free software; you can redistribute it and/or # modify it under the terms of the GNU General Public License as Now when you do an svn diff, svn is smart enough to reduce $<keyword> text$ to $<keyword>$. But your local checkout still has the last patch information in. Since $<keyword>$ is part of the synchronization lines (not the add/remove part), patch will directly reject this diff, as unified diff relies on the fact that the sync-lines (usually 3 of them) are identical. It is true that people rarely would submit patches for stuff *around* $<keyword>$s, but it is still an inconvenience when it happens. If you still want to use those, I would recommend enclosing all auto-substituted lines in 3 do-not-change comment lines before and after. This way no patch will be perceived broken, unless someone starts working on the keyword line itself (and then he knows what is he up against). * Apologies to jawnsy, for accusing him of doing stuff unannounced. Fault is equally ours (#dbic folk) for missing this thread. ------------------------------------------------------------------------------ Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com -- sqlfairy-developers mailing list sqlfairy-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sqlfairy-developers
