4 ms·

> It is possible, or even likely, that a repository switch could lose that history on a project like emacs. Surely the "D" in DVCS means that many thousands of

by zephod 11y ago

> It is possible, or even likely, that a repository switch could lose that history on a project like emacs. Surely the "D" in DVCS means that many thousands of copies of the project history would be available around the world?

LukeShu 11y ago
When the code was commented out, it would be several decades before Emacs would be switched in to a DVCS, then another 7 years from when the "please don't delete this" comment was added. Even if it was in the DVCS history, and there was a comment pointing to a commit ID, that would have been rendered nonsensical by the conversion from bzr to git.
- paulddraper 11y ago
  Nonsensical, but still accessible
- philh 11y ago
  I'd be somewhat surprised if the bzr->git conversion did in fact mess those up. I was following ESR's blog when he was doing the conversion. He seemed to feel very strongly that the conversion should not mess things up like that. (His goal was that the history should look like it would have done, if people had always been using git.) On the other hand, I'm less confident about the conversion to bzr. And anyway the relevant question is not "would it have broken?" but "did people have reason to expect it would break?" And on the third hand, a commit id could be referenced by author and timestamp, which would be invariant under (competent) repo conversions.
  - LukeShu 11y ago
    The bzr->git conversion does look like it was always in git from a looking-at-the-repo viewpoint (sans commit messages mentioning RCS/CVS, et c.); but in-repo data wasn't changed much; when building from VCS, it sticks a VCS identifier in the version; prior to a certain commit the script for that tries to grab the commit ID from bzr instead of git. However, ESR's blog does suggest that commit hashes mentioned in the source were replaced; I'm not sure if that's true. That said, referencing the commit by author and timestamp, instead of internal commit ID is the robust solution.
- Cyberdog 11y ago
  Did they not record the bzr commit IDs in the Git commit messages during the conversion? If they did, finding a Git commit that corresponds to a bzr commit ID should be trivial.
  - wainstead 11y ago
    In a perfect world, sure. I once worked for a company that bought another company's assets (mainly the code base) and at some point in the past the code base had been migrated from CVS to Subversion and the commit history was simply lost. They probably just took a clean copy of the main branch and started a new repository. "Why was this written this way?" was not a question you could unearth from the repository, sadly. (Another company I worked for had commit log entries like "I like cheese" so perhaps this company wanted to erase history for a reason. Here in the 21st century version control systems finally get the respect they deserve, though I bet there's a sad number of shops that still don't use one).
- zephod 11y ago
  But you could _delete it today_ and it would not be lost. Right?
zephod 11y ago
No idea why this was downvoted. Perfectly legitimate question given unclear circumstances.

by zephod 11y ago

LukeShu 11y ago

When the code was commented out, it would be several decades before Emacs would be switched in to a DVCS, then another 7 years from when the "please don't delete this" comment was added. Even if it was in the DVCS history, and there was a comment pointing to a commit ID, that would have been rendered nonsensical by the conversion from bzr to git.

paulddraper 11y ago
Nonsensical, but still accessible
philh 11y ago
I'd be somewhat surprised if the bzr->git conversion did in fact mess those up. I was following ESR's blog when he was doing the conversion. He seemed to feel very strongly that the conversion should not mess things up like that. (His goal was that the history should look like it would have done, if people had always been using git.) On the other hand, I'm less confident about the conversion to bzr. And anyway the relevant question is not "would it have broken?" but "did people have reason to expect it would break?" And on the third hand, a commit id could be referenced by author and timestamp, which would be invariant under (competent) repo conversions.
- LukeShu 11y ago
  The bzr->git conversion does look like it was always in git from a looking-at-the-repo viewpoint (sans commit messages mentioning RCS/CVS, et c.); but in-repo data wasn't changed much; when building from VCS, it sticks a VCS identifier in the version; prior to a certain commit the script for that tries to grab the commit ID from bzr instead of git. However, ESR's blog does suggest that commit hashes mentioned in the source were replaced; I'm not sure if that's true. That said, referencing the commit by author and timestamp, instead of internal commit ID is the robust solution.
Cyberdog 11y ago
Did they not record the bzr commit IDs in the Git commit messages during the conversion? If they did, finding a Git commit that corresponds to a bzr commit ID should be trivial.
- wainstead 11y ago
  In a perfect world, sure. I once worked for a company that bought another company's assets (mainly the code base) and at some point in the past the code base had been migrated from CVS to Subversion and the commit history was simply lost. They probably just took a clean copy of the main branch and started a new repository. "Why was this written this way?" was not a question you could unearth from the repository, sadly. (Another company I worked for had commit log entries like "I like cheese" so perhaps this company wanted to erase history for a reason. Here in the 21st century version control systems finally get the respect they deserve, though I bet there's a sad number of shops that still don't use one).
zephod 11y ago
But you could _delete it today_ and it would not be lost. Right?

zephod 11y ago

No idea why this was downvoted. Perfectly legitimate question given unclear circumstances.