4

I am in the process of converting a CVS repository to Git.

Currently, all developers commit any changes that they make to HEAD in CVS. Testing is done on a version of the application that is the latest from HEAD. I have an automatic script that uses git-cvsimport to bring all new commits into a Git repository. Whenever a new commit comes in I cherry pick it onto a feature branch based on the ticket number in the comment. (If there is none I yell at the developer who committed it that way, :-)) We package are production version by merging entirely with Git, although I do have a script that tags a CVS branch as well so that the developers can know what production is up to.

My end goal is to finally wean ourselves off of CVS once, and for all. However, I am not currently in the position to force the issue, so I need a workaround. I want a workflow where some users can use Git exclusively, and then merge their changes into a Git development branch, but still somehow export their changes back to CVS without to much hassle. This way I can incrementally bring developers into Git without having to make an all-or-nothing switch.

I have no admin rights, so it will be hard for me to do anything that involves setting up proxies.

Any ideas?

Joseph K. Strauss
  • 4,683
  • 1
  • 23
  • 40
  • Just to clarify: I cannot really do anything to the CVS server, but I could put all the hooks I want on the Git server, and commit automatically to CVS. However, my issue is how to make sure that someone committing to the Git development branch will not overwrite changes in CVS. – Joseph K. Strauss Dec 28 '14 at 18:55

1 Answers1

0

Here is a blog post that seems to give the answer:

CVS to GIT and back

Jacques
  • 123
  • 1
  • 3
  • Since this is not a must-read (such as the the Git documentation), please give your answer how to do it (with the appropriate markdown's) so that your answer will have useful information for Stack Overflow users. – Joseph K. Strauss Jan 25 '15 at 21:02