What is a reasonable mixed workflow for git/git-cvsserver?

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

Hi,

On Mon, 23 Jul 2007, Steffen Prohaska wrote:

This is what we did here:

We cvsimported the whole stuff (but we did not have your problems, since there was only one branch). Then we initialised a shared repository with that branch, turned on git-cvsserver (and found a few bugs, but that was long ago, and AFAIR all our issues were fixed) and went to work.

There were a few committing via cvs, and a few others committing via git. One person only tracked via cvs, not contributing code, just reviewing and testing.

We did not have the need to impose certain restrictions, such as git-shell (to prevent invoking other programs), or hooks refusing a push that touches parts the person pushing has no business changing.

But we had the option to go there, if needed. So far, all went fine. And I'm convinced that it is partly because of the trust model. After all, I still have my local repository. And that I can trust at all times.

So if a poisonous person (instead of thrashing the mailing list with long mails) would have decided to corrupt the repo, we would have realised that pretty quickly, repaired the damage without much effort, and kicked out that person.

Needless to say that all our devs converted to Git. And I'm happy to say that they're all happy with it.

Ciao, Dscho

On 7/23/07, Steffen Prohaska <prohaska@zib.de> wrote:

It was written on the concept that the core developers would switch to git and occassional committers and less sophisticated SCM users like translators would be able to continue using cvs.

Basically, cvs users can no longer tag or open new branches. So your plan is exactly what we set out to support. Switching branches is not possibe -- that's unfortunate, but emulating CVS's branching is a bridge too far :-)

I am not sure what you mean by unsorted commits... "proposed patches"? The git project itself has a proposed-updates branch that might serve as an example. And repo.or.cz has the strange concept of the mob branch that you might want to have a look at.

cheers,

martin

On Jul 23, 2007, at 12:59 PM, Martin Langhoff wrote:

The mob branch seems to be related, although I do not plan for an anonymous mob but only for the cvs mob ...

If several people commit to the same shared branch exported by git-cvsserver they most likely will generate a series of unsorted commits, as they did in the past on a single cvs branch. The commits will probably deal with various topics, include bug fixes, and some are likely more experimental and not really ready for a stable branch.

My question is how to deal with this shared branch on the git side. Should a core developer rebuild a sane history from such a shared/mixed/unsorted branch by cherry picking the commits to one or more topic branches? If one did so, how could one bring the git-ish history back to the people connected by cvs? Am I allowed to reset branches exported by git-cvsserver? Probably not?

	Steffen

On 7/23/07, Steffen Prohaska <prohaska@zib.de> wrote:

Keep the good commit message practices ;-) in my projects I tend to mimic the linux and git "style" for commit msgs.

I think that's usually frowned upon. As the committer did his/her work on a particular state of the tree, and tested it. So every commit at least *should* be of a working state. Once you rewrite history as a "normal" practice, that flies out of the window. And it's a big loss.

In a sense, it's a "history that looks tidy but is false". And it's extra work too. I very strongly prefer good commit messages, and the real history.

Indeed not. Junio rewinds/rebases pu (the proposed updates branch mentioned earlier) regularly, but you can only do that in a pure-git project, and with fairly experienced git users (so if they get caught with commits on top of a rewound pu branch they'll know what to do). cvsserver doesn't know what to do with rewinds/rebases and, more importantly, cvs clients can't cope with it. And that is something we cannot fix, unfortunately.

cheers,

martin

On Jul 23, 2007, at 10:19 AM, Martin Langhoff wrote:

That's only somewhat true. First, there's never a guarantee that the committer tested it, especially if they had to pull before committing (less likely they tested the resulting merge than tested their original code). Second, rewriting history isn't a big loss. It's done all the time here on this list. The patches I've sent in rarely appear applied on top of the commit I made them from. The mob branch could just be viewed as a set of patches to use, and it becomes the maintainer's job to test the results after cherry-picking from them.

~~ Brian