At 07:42 AM 12/16/2005 -0800, Michael Chermside wrote: >Phillip writes: > > FYI, this is not the true revision number; it's only the revision number in > > which the directory was last modified, not the latest revision number > > within the tree. > >Barry responds: > > I opted against that for several reasons. First, I wanted to keep the > > patch as simple as possible. Second, I didn't want to depend on Python > > already being built [...] Third, I > > think most Python developers will just svn up at the top of the source > > tree, then rebuild, rather than svn up some buried sub-tree, cd back to > > the top and rebuild from there. > >I agree with Barry. If you have done your "svn up" from anywhere other >than the root, then you are building Python with a mix of revisions. I >think that sys.build_number should produce undefined behavior when >executing in a Python built from mixed revisions -- anyone doing this >gets what they deserve.
The "Revision" from "svn info" isn't reliable; it doesn't actually relate to what version of code is in the subtree. It can change when nothing has changed. For example, in my setuptools checkout, I just did an "svn up", and the "Revision" is now 41708. But *nothing* in the tree has changed since 41701; this is simply the current highest SVN revision, repository wide. When people change things in branches, the sandbox, PEPs, etc. - that number will change, even though nothing changed in the trunk. I suggest that having an SVN revision number that changes when no code has actually changed is confusing and unreliable. SVN does track the actual *changed* revision, it just takes a little more work to get it. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
