Community
Participate
Working Groups
We have been planning our CVS->git migration for this summer. One of our requirements is the ability to build and release code to old streams without having to update all the old build scripts etc to support git (for example 3.2.x). John has suggested setting up a git->CVS read only mirror to facilitate this use case. We would commit the code change to git but still build the old streams from the CVS read-only mirror. This might also be useful for those parties who are interested in long term Eclipse support. It seems that there are already tools to do this. See http://stackoverflow.com/questions/584522/how-to-export-revision-history-from-mercurial-or-git-to-cvs/584567 and git cvsexportcommit command. How do you feel about implementing a read only CVS mirror of our future git repositories on an ongoing basis?
This would also be interesting for users of Indigo and earlier releases where the shipped plug-ins already contain Eclipse-SourceReferences entries in the manifest. If the CVS server is shut down completely, then all these references are destroyed and people cannot easily import projects any more to fix a problem and create a patch.
After some discussion today between Kim, myself, and some Foundation folks, we decided an automatic Git->CVS mirror is not needed. Because the mapping between Git and CVS is non-obvious and rough around the edges, we wouldn't be able to rely on branch/tag information from such a mirror. I.e., we wouldn't be able to trust running builds against it. We are still interested in keeping our current CVS repository around in read-only form for a transition period after our migration to Git. Example use cases: - Eclipse-SourceReferences in previous releases that cannot be changed - People using products based on Eclipse 3.6 or earlier which does not have a Git client - Any number of tools, build scripts, and web sites with existing pointers into our CVS repository that would be broken by it going away - Because the branch transition from CVS->Git is error prone, having the CVS repository around for reference would be helpful if we discovered problems with our Git branches/versions on old content. I'm removing the blocking reference because this is an issue for after our migration. Typically the foundation keeps all CVS repositories for six months after transition to Git, but what we would like here is some kind of extension on that.
We can certainly keep the CVS data around longer if required. Just let us know when(and what!) to flag as read-only when you're ready and we can discuss how long to keep it then. -M.
Couldn't we just install git-cvsserver [1] so that we can access the Git repo via CVS? [1] http://www.kernel.org/pub/software/scm/git/docs/git-cvsserver.html
(In reply to comment #4) > Couldn't we just install git-cvsserver [1] so that we can access the Git repo > via CVS? If the purpose is to build old streams, git-cvsserver would be a step backwards (vs. running CVS in read-only mode). CVS is already installed and configured, and it natively "talks" CVS, so we have nothing to do. git-cvsserver would need to be installed and configured, and we all know it won't get the branches and tags right, which will lead to bugs and wasted time for everyone.
I think this has all been sorted out. Please reopen if I've missed something.
