Re: cvs2git: One possible bug, and two other issues

On Mon, Jan 24, 2011 at 2:17 PM, Greg Ward <[email protected]> wrote:
> 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.

The tag pairs are needed to preserve history.  We have to handle
multiple release branches, and the tags are used to delimit eg.
bugfixes so they can (more) easily be merged to other branches.  I
know that this will be much easier in Git - and we'll likely not need
to make new tag pairs.  But we do need all the old ones from the CVS
days for some time to come ...

> 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?)

Well, I don't expect the number of tags to affect normal operations
much.  If the operation doesn't use tags at all there is no effect,
and in many other cases a tag is used only once in the beginning of
the operation.

Apart from that I just looked, and there is a command 'git-pack-refs'
which packs tags and branches similar to blobs.

Even so, if the number of tags becomes a performance problem anyway,
we still have the option of deleting the tags later on.  So my plan is
still to go ahead and convert all the tags.

But thanks for the warning!

Best regards,
  Anders Pilegaard

------------------------------------------------------
http://cvs2svn.tigris.org/ds/viewMessage.do?dsForumId=1667&dsMessageId=2700121

To unsubscribe from this discussion, e-mail: [[email protected]].