Showing content from http://mail.python.org/pipermail/python-dev/attachments/20090703/fa394dbe/attachment.htm below:
<br><br><div class="gmail_quote">On Fri, Jul 3, 2009 at 14:52, "Martin v. Löwis" <span dir="ltr"><<a href="mailto:martin@v.loewis.de">martin@v.loewis.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">> We could add another value in the tuple that specifies the VCS:<br>
> ('CPython', 'branches/release25-maint', '61464', 'svn'). I agree that<br>
> VCSs are not universally the same, but the concept of a revision is<br>
> universal.<br>
<br>
</div>Actually, I think that's not the case. For bzr, the usual way of<br>
identifying a revision is by revision number, which, however, is not<br>
unique within a project, as each branch will use contiguous integers<br>
for numbers. There are also unique identifications - so a bzr revision<br>
has actually two numbers.<br>
<br>
More general, in a DVCS, it is not possible to access the revision being<br>
referred to by such a tuple. For sys.subversion, if [0]=='CPython', then<br>
you could go to <a href="http://svn.python.org" target="_blank">svn.python.org</a>. For a DVCS, the revision being<br>
identified may not be publically available, or may not live on a host<br>
that you can infer from your proposed sys.revision.<br>
<br>
For cloned branches, I wonder how sys.revision[1] would be computed.</blockquote><div><br>So are you saying we should drop the idea of a revision value altogether, or just embrace the differences and add a sys.mercurial attribute?<br>
<br>-Brett <br></div></div>
RetroSearch is an open source project built by @garambo
| Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4