5 ms·
Sure but then you switch Version Control systems later and the hash/vcs command may not mean anything.
by lqdc13 11y ago
Sure but then you switch Version Control systems later and the hash/vcs command may not mean anything.
- nailer 11y agoI wasn't around when rcs was a thing, but cvs to svn and svn to git preserved history.
- revelation 11y agoIt will automagically scan through all files and replace what looks like a revision number with the correct git hash?
- asdfaoeu 11y agoI don't know about the cvs to svn migration but migrating from git to svn you generally can keep the original svn commit numbers in the history such that you can look up svn revision numbers like that.
- jheriko 11y agohe means replacing comments mentioning revision numbers. no source control migration does this - it would be harmful if done unchecked (revision numbers like 1 will turn into compile errors or very confused comments in the most naive implementation, for example)
- LukeShu 11y agoExactly. Emacs has changed VCS at least 4 times since the code was commented out. (pre-RCS (no VCS?) -> RCS -> CVS -> bzr -> git) I've had codebases with references to bug IDs... from 3 bug trackers ago.
- LukeShu 11y agoI can't seem to edit the comment, but: change that to 5 times, they used Arch between CVS and bzr.
- weinzierl 11y agoWith a capable vcs you don't need a version number, hash or other id. These things are always fragile. Just add a comment saying that this is a rewrite of the old part the code and document any intended functional differences. You can then search through the history for the first appearance of that specific comment. With git this is done with the pickaxe command.
- shawn-furyan 11y agoI think the issue here is that as nice as you might find your VCS tools when you write code, the code you are writing, particularly on code bases that are already old, may survive significantly longer than the current hot VCS. If the entire commit history gets squashed when the code base is ported over to a new VCS, then VCS history may not be robust enough to communicate with maintainers in the distant future (that is, potentially a decade or less from now given the typical half life of these sort of tools).
- kalleboo 11y agoI don't blame the devs 30 years ago for being cautious but now emacs has survived 5(?) VCS migrations with all the data intact, the tools are more mature now and it shouldn't be a worry anymore.
- shawn-furyan 11y agoPerhaps what we need are reliable tools that will robustly port commits forward from old VCSs to new ones. Does something like that exist? The most common defense of this code seems to stem from a vague sense that VCS history is more ephemeral than committed code. With proper tooling (or better awareness of the appropriate tools if they do in fact exist), this anxiety could potentially be allayed.
- telotortium 11y agoEric S. Raymond wrote a tool called reposurgeon[0] for just this purpose. Coincidentally, he used it to migrate Emacs to Git and clean up the repo, although I'm not sure how much manual work he had to do to besides running reposurgeon. [0] http://www.catb.org/esr/reposurgeon/ http://www.catb.org/esr/reposurgeon/ [1] http://esr.ibiblio.org/?p=6524 http://esr.ibiblio.org/?p=6524