2

This is a multiphase question. I am looking for the current state of the art to completing it and linking separate resources doing disjoined parts.

Short story of what I need:

  1. convert a full-history CVS repo into git as a base
  2. concatenate an existing git repo for that same project on top of the above
  3. publish the merged repo on github
  4. merge in forks from the 2nd step

My issue is as follows (a longer story):

  • I have a relatively large original CVS repo, let's call it O_cvs with some branches, tags, etc., lots of history for over 10 years.
  • At some point a copy (one of) of a checkout of that repo O_cvs was made and pushed into a Git repo as a starting point, let's call it O_git. There were no further commits to O_cvs; nor further development is planned in O_cvs after migration.
  • O_git had a number of features added and projects forked, some are merged via pull requests and some aren't, say F1_git, F2_git, etc.

Thus, my plan with question where appropriate:

  1. I care for the history and contributors and tags in O_cvs that I would like to preserve as a base. As a result I would like to produce a repo, let's call it G_git (local?) from O_cvs. What's the current recommended tool to do that for me? I researched here and elsewhere and found different suggestions posted over the years featured, e.g., in here, here, and here:
  2. I then plan to publish G_git on GitHub (only question here should this be the order), as G.
  3. I care for the O_git and its forks, hosted elsewhere, so I'd pull that in.
  4. I want to concatenate the histories of G_git + O_git, and push them to GitHub, into the combined repo G. From my research "grafting" and fast import seem the way to go here.
    • so would I graft O_git onto G_git on GitHub (should grafting be done before pushing G_git to GitHub?)
  5. I will work on pull requests to O_git from F1_git, F2_git, etc. (may take awhile, but G needs to be out sooner) to integrate them into G (will there be a problem? do I have to go through the intermediate steps to O_git, and then via an additional remote to G?)

Recommendations on the current tools and the sequence above and associated pitfalls are appreciated.

Community
  • 1
  • 1
Serguei
  • 236
  • 3
  • 12

1 Answers1

0

The best recommended solution (I'm well experienced in that issue) is to keep the CVS repo as read-only repository and merge the latest revision to the git repository without history. You'll benefit from it a lot for the long run!

About the tool for the migration, try (my tool): https://github.com/tikalk/tikal-alm-tools

yorammi
  • 6,272
  • 1
  • 28
  • 34
  • your tool under the hood uses `cvs2git` -- why that choice specifically? I also care for the history and contributors especially in `O_cvs`. – Serguei May 30 '16 at 12:51
  • forgot to mention the CVS repo isn't planned to be used for development in the future after migration completes. I will edit the question to that effect. – Serguei May 30 '16 at 13:51
  • Well, I wrote it long ago so I don't recall why but it worked for me for migrating several customers-projects – yorammi May 30 '16 at 18:15