[Python-Dev] Expose Subversion revision number to Python
Phillip J. Eby
pje at telecommunity.com
Fri Dec 16 22:25:58 CET 2005
At 10:03 PM 12/16/2005 +0100, Martin v. Löwis wrote:
>Phillip J. Eby wrote:
> > But you can also have more than one revision number that represents the
> > *exact same code*, with no changes at all.
>
>That's correct. I don't see this as a problem - in particular not in
>the context of the proposed patch.
>
>The idea is that you can reliably tell what code base a certain
>executable image originates from. With that patch, you can
Only if you do an "svn update" immediately after *every* "svn
commit". Otherwise, the code base reflected will be a version *before*
your changes. This is fragile, since not everyone will know (or remember!)
to do this.
> > It can also give you a false indicator of change, when nothing has in
> > fact changed. Don't believe me?
>
>I believe that the version number changes. It is a false indicator only
>if you are unaware of that fact. To me, different version numbers don't
>indicate different code bases, because I know how subversion works.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Exactly my point. The proposed mechanism relies on an intimate
understanding of how subversion and its revision numbers work, making it
unnecessarily fragile when used by Python developers and the community at
large.
> > I'm rather baffled as to why everyone seems so insistent on not using
> > "Last Changed Rev" and "-R"
>
>That's easy to tell: because it is expensive.
I doubt that's the actual reason, but it seems like a bad reason in any
case; it seems to me the applicable Zen should be "never is often better
than *right* now". :)
That is, if you're going to rely on a number that can be falsely high or
falsely low depending on the detailed development practices of developers
working on the trunk or anywhere else, it seems like wasted effort. Trying
to diagnose a problem with wrong information is worse than having *no*
information.
Thus, I'm -1 on including a revision number that will be frequently wrong
(high *or* low) in practice. If it's too "expensive" to do it right, it's
*definitely* too expensive to do it wrong. :)
More information about the Python-Dev
mailing list