Re: cvs2git: One possible bug, and two other issues
Greg Ward <[email protected]> Mon, 24 Jan 2011 08:17:46 -0500
| Newsgroups | gmane.comp.version-control.subversion.cvs2svn.devel |
|---|---|
| Message-ID | <[email protected]> |
On Sun, Jan 23, 2011 at 6:27 PM, Anders Pilegaard <[email protected]> wrote: > Besides, we have a lot of begin/end tags where it is very important > that the diff between such tag pairs is preserved in the conversion. > So I think we'll just have to live with the fixup commits ... It sounds to me like you are not taking full advantage of the conversion to a modern, capable, sanely designed DVCS. Switching from CVS to hg or git obviously requires learning new ways to commit changes, browse history, etc. But that's the *small* change. The big change is to your workflow. If you plan to keep using those tag pairs in the future with git, you are missing the whole point of git. If you are only keeping them for historical purposes, consider the cost *very very* carefully. My experience was with converting a large CVS repo that used 10s of thousands of tag pairs over the years for marking and merging bug fixes. They were essential to get correct behaviour out of CVS, but completely superfluous with Mercurial. So we dropped them in the conversion. This is particularly important with Mercurial, since having tens of thousands of tags would have a performance hit with many common hg operations. I don't know if the same is true of git, but I would bet good money that git simply was not designed to handle that many tags. (It keeps them as tiny files in a directory, right? So how well does your filesystem deal with that many files in one directory?) In the year since we switched to Mercurial, I have not heard a whisper of a complaint about the loss of those tags. hg log does a far better job of reconstructing old history than those silly tags ever did. Greg ------------------------------------------------------ http://cvs2svn.tigris.org/ds/viewMessage.do?dsForumId=1667&dsMessageId=2700116 To unsubscribe from this discussion, e-mail: [[email protected]].