Git/Mercurial locally ontop of local cvs checkout

I have read :

• "Best practices for using git with CVS"
• "How to export revision history from mercurial or git to cvs?"

, and neither suit my needs.

At work we use a remote CVS repo. Access to this repo is handled via eclipse CVS tools, and in-house eclipse plugins that are built ontop of team tools for eclipse. This means we can't move to a better vcs.

However I would like to use Git on my local machine (to enable personal branching) such that I can accomplish the following:

Create branches in Git and then once finished and merged back into my local trunk, commit back to the cvs repo using the eclipse team tools etc.

My plan is something along the following lines:

• Copy the checked out files to another folder [gitRepo].
• Create a master git repo in gitRepo
• Branch in gitRepo and make changes.
• Commit to gitRepo
• Copy gitRepo back to checked out files
• Sync with remote cvs.

I was planning on using eGit for eclipse however I believe that the CVS and .git files will compete for ownership of the versioning.

Are there开发者_如何转开发 any tools or suggested work flows to help me manage this? Also how well does Git play with CVS files. And vice versa since I don’t want them to infect each other.

The reason the former links are of no use is they commit straight to the cvs repo from the git repo and this worries me as I do not wish to infect the cvs repo by accident.

It should also be said that changes in the GitRepo do not need to persist into the CVS repo, for example I don’t need to see every push to the git repo reflected in the remote CVS.

~Thanks for reading.

You perfectly can create a git repo directly within a CVS workspace (much like directly within any other VCS tool.

Make sure git will ignore any .cvs resources, and make sure CVS will ignore the .git.
Any Git commit won't be directly reflected in CVS.

The only trick is for Eclipse to display only Git or only CVS informations and label decoration.
For that I would configure two different Eclipse perspectives in which I will de-activate one or the other VCS tool.

I have done exactly this at work and I found the following practices helpful:

1. Keep any one (master in my case) branch always in sync with CVS. Do not use this branch for your development. Periodically update this branch to get the changes made by the rest of the team. If these changes are relevant to your current work do a merge master from your dev (or any other appropriate) branch.

2. When you are ready to check in to CVS switch to the master branch and merge the changes from the appropriate branch (dev, feature etc. as appropriate). Run your tests!

3. You employer most likely will keep a back up of the CVS repos. You will have to find a way to keep your git repo backed up. One way is to add a mirror repository in a Dropbox folder and use a post-commit hook to update it after each commit.

4. Before you leave work switch to the master branch. I once made the mistake of running CVS up -d on a dev branch in the morning and ended up quite confused. Adding a script to automatically switch to master before updating helps.