I don't remember the story behind cpython-fullhistory, but it's obviously incomplete since just stopped post conversion. You will need to find someone who knows (I'd ask on python-dev). <div><br></div><div>Also realize that this will be  our fourth VCS (cvs, svn, hg, now git). This is not going to be a perfect history of the semantic actions of commits from the beginning of time just due to the fact that these VCS tools all use different concepts. <br><br><div class="gmail_quote"><div dir="ltr">On Thu, Feb 11, 2016, 22:04 Martin Panter <<a href="mailto:vadmium%2Bpy@gmail.com">vadmium+py@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 12 February 2016 at 03:07, Brett Cannon <<a href="mailto:brett@python.org" target="_blank">brett@python.org</a>> wrote:<br>
> On Thu, Feb 11, 2016, 16:43 Nicolás Alvarez <<a href="mailto:nicolas.alvarez@gmail.com" target="_blank">nicolas.alvarez@gmail.com</a>><br>
> wrote:<br>
>> I tried fast-export, and I don't really see anything wrong with the<br>
>> repository. The size is 221MB.<br>
<br>
One thing I’m slightly curious about is how much the result differs<br>
from <<a href="https://github.com/python/cpython" rel="noreferrer" target="_blank">https://github.com/python/cpython</a>> or other results, and if so,<br>
what the differences are. The differences could be serious (mangled<br>
history), or they could be trivial things like stripping trailing<br>
newlines from commit messages, or skipping commits that don’t change<br>
any files.<br>
<br>
>> It depends on how crazy you want to go. For example, SVN-era merges<br>
>> don't appear as merges, but looks like some SVN-era branches don't<br>
>> exist in Hg to begin with (Would I need to get cpython-fullhistory?<br>
>> Cloning it gives me a 400 Bad Request). Do we care about that?<br>
><br>
> Good question. If you are not an even clone it then that shows how much<br>
> people who are. Honestly I wouldn't worry since we have the history in the<br>
> hg repo (converting from svn was necessary to have it available without the<br>
> server).<br>
<br>
I care a bit. If I get the time, I would like to figure out a robust<br>
way to convert the Subversion history to Git so that the svnmerge<br>
information is included as proper merges.<br>
<br>
Another concern for me is that some of the useful history is not even<br>
in Mercurial. For example <<a href="https://hg.python.org/lookup/r70152" rel="noreferrer" target="_blank">https://hg.python.org/lookup/r70152</a>> is an<br>
svnmerge from ^/python/branches/io-c into ^/python/branches/py3k, but<br>
the Mercurial repository doesn’t have the branch history, so all the<br>
merged-in Subversion revisions such as r68683 are missing.<br>
<br>
Some other highlights on my quest to investigate the holy Subversion<br>
respository (I can post my full notes somewhere if ppl are<br>
interested):<br>
<br>
* It is nice to have a local mirror of the Subversion repository so<br>
that experimenting with different options and programs isn’t horribly<br>
slow. But I don’t want to mirror everything or overload the server<br>
because there are other projects stored in the repository that seem to<br>
take up a lot of space (and download time).<br>
<br>
* What is the story with the cpython-fullhistory Mercurial repository?<br>
On the surface it almost looks like an out-of-date copy of the main<br>
repository, but I notice some subtle differences, e.g. revision ids<br>
for early tags are different, v1.0.0 tag is added.<br>
<br>
* Some Subversion revisions actually merge stuff from outside the<br>
Python tree (e.g. <<a href="https://hg.python.org/lookup/r88662" rel="noreferrer" target="_blank">https://hg.python.org/lookup/r88662</a>> from<br>
^/sandbox/trunk/2to3/lib2to3 into<br>
^/branches/release27-maint/Lib/lib2to3. Not sure if it is worth trying<br>
to salvage these merges; I never noticed them when working on Python.<br>
<br>
>> Or, changes that come from non-committers could have their Author<br>
>> field modified, maybe based on the ACKS file modification. It's<br>
>> feasible but will take time and manual work. Do we care about that?<br>
><br>
> That would be great but too much effort.<br>
<br>
I think it would not be worth it, and could even be detrimenal. You<br>
would be trying to guess based on incomplete and unreliable<br>
information. Maybe one person wrote a test, another wrote the<br>
implementation, and a third wrote the documentation, but it was all<br>
committed at once. Maybe the author was already in ACKS and the<br>
committer did not mention who the author was in the message. I think<br>
it is safer to not pretend the author field is alway accurate.<br>
</blockquote></div></div>