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]].