I plan to migrate a project from cvs to git and provide legacy support for cvs users through git-cvsserver. It's not realistic to teach all people at the same time to use git. We need some early adopters first. It is also likely that we start migrating only parts of the repository and keep some other parts in cvs. I plan to start with parts for which the benefits of git's support for merging are most obvious. What's a reasonable workflow when some people use git and other people use git-cvsserver simultaneously? I can imaging that we try the typical git model with developers who are using git. Developers would clone to private repositories and ask upstream maintainers to merge. I'm wondering how to integrate people that will not yet use git but checkout and commit through git-cvsserver? We could easily arrange a stable branch for cvs access that should be accessed read-only. Work merged using git would be published to this branch. I can also think of specific topic branches that are created upon request by a git expert and accessed from cvs through git-cvsserver. Merging could be done by a git expert using git. An inconvenience is that people must do a fresh checkout to switch to a topic branch but can not use 'cvs up -r'. At least this is my understanding of git-cvsserver's documentation. I have no clear idea how to deal with the shared rest. We typically share work in an unsorted way on a cvs branch, which everyone commits to. I think we'll need a similar possibility, at least for a transition period. We could create such a shared branch for access from git-cvsserver. What is a reasonable way to handle the unsorted commits from a shared branch in a more git-ish way? I googled a bit but didn't find a good explanation on the web. Any ideas, any real-world experiences? Steffen - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
