[Python-Dev] Expose Subversion revision number to Python (original) (raw)

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