The biggest fly in the ointment is that most of the documentation and tutorials are directed at starting a new project with git. Everything is clean and easy. Pulling in a large cvs project is not documented, and I have no idea how to check that everything is done correctly. Maybe the cvsps tool has more documentation, since this is what is doing the difficult task, and is applicable to more than just git, maybe it would help the conversion to subversion?
My typical method of development with OpenACS is to download the most current stable version and then develop on that. But I seldom make any core changes. The problem for me is not pushing changes back, but merging in new updates from OpenACS, but git or svn may not make things any better because this isn't just source code, but also datamodel and data. And there is the potential for lots of one-off edits to local files that you don't normally see in code development.
Pushing and pulling into a production environment probably shouldn't extend to any shared repository, this is the point of git: everyone shares what they want and pulls from these shares what they want (into their own repository). At some point, an official version can come out, but if your specialized code isn't in the official version, it doesn't mean you are cut off. So if you develop a feature which only you find useful, maybe it stays in your local branch. Then if someone else picks it up, maybe generalizes it, it might work its way up into the main branch. If the point is to maintain a monolithic repository, there is no need to move to git, it isn't really directed at shared repositories.
So what you might do as a developer with multiple clients is to maintain a development repository with branches for each client, or a private repository for each client, but the private repositories would still reference your local repository, which would eventually reference the openacs official version/branch/tag.
As far as merging stuff from git back to cvs, I don't know if that is possible. What I was interested in doing is pulling down new cvs commits. I have heard that developers are pulling from svn, merging and then pushing back into svn, so maybe you can do the same with cvs.
