Arne Goedeke wrote:
There are some places in the Pike code where CVS keyword substitution is used (like $Revision$ in Tools.pmod/Standalone.pmod/module.pike). In some cases, like this one, where those keywords are used outside of comments problems appear (doesnt compile). Any workarounds for git?
I'm not quite sure how important the automatically visible version is in the places where it is currently used. It's not in a lot of places, it might be worth eliminating or creating a real workaround; however...
Also with this particular case (when the first constant is wrong), pike segfaults, apparently in f_function_name called by _sprintf in the last backtrace frame of that compile error.
In order to have something that works, I've created two branches (branches are really cheap in git; it's not unusual to create and delete two temporary branches a day):
git log origin/BuGless # My 7.7 branch which only holds the # patches on top of 7.7 which I # haven't checked into the master # CVS version yet.
git log origin/debian-be # The Debian Bleeding Edge version # I'm currently trying to maintain
Any thoughts about the $Revision$ dependencies?
I know that the fixes I checked into the BuGless branch are not real solutions, they just set it to static version-like strings (2.0); it should be carefully evaluated what the version number was intended to convey (and subsequently you can either drop it completely, or provide a good alternative). The reason why git doesn't endorse things like $Revision$ is because: - It needlessly clutters the diffs from revision to revision. - There is no such concept as the "revision number" in a (potentially) distributed revision control system as git (it *can* be centralised, though, and yes the numbers can still be generated, but it largely depends on what you really want to show).
On a related note, any objections against checking in the debian/ support tree into the master CVS?