[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