bren...@mozilla.org schrieb:

 From what I've read, the MinGW port of git is working and performing
quite well, it has been started as a fork of mainline git but it is
intended to be merged upstream once someone comes around to introduce
the necessary #ifdefs to sort out what to compile where.

Bulding on MSYS and MinGW, it also would fit well with our targeted
Windows build infrastructure, I guess.

Main sources for this info are the gitweb page of the MinGW port
http://repo.or.cz/w/git/mingw.git as well as its README.MinGW
http://repo.or.cz/w/git/mingw.git?a=blob_plain;f=README.MinGW;hb=master
and the git mailing list g...@vger.kernel.org which I glanced on a few
times via gmame.

Well, locked out might be the wrong term. I just quite sure that many
people will just not care about the Mozilla2 repo if working with the
old CVS is not only what they're used to but also a lot easier, not
needing to set up multiple repositories etc.
This in turn will likely keep them away from Mozilla2 work, splitting
the project and removing them from the edge of development (even though
not directly _locking_ them away from it).

It might turn out completely differently, I'm just expressing what I
fear will come out of that.

Or even more than two, when I think of someone wanting to build
Thunderbird+Lightning at once or even SeaMonkey+Lightning (normal
SeaMonkey can already run into problems with the mailnews backend being
shared with Thunderbird). And what about builds including Venkman or
Chatzilla?

This all is so easy to do with a big shared repository and can get very
complicated with splitted repositories, which makes quite reservated
about that approach.

Another thing is needing to pull a completely different repo just
because you want to help a different project and do a patch for them,
e.g. for webtools or such. With the current approach, the nice thing is
you can easily go, pull that dir in your trunk tree, hack a patch, post
it on bugzilla, check it in after appropriate reviews. Pulling lots of
different repositories in different dirs can easily get annoying enough
that people get scared away from such cross-project help.

That would sound nice, but we probably first need to find out what is
easily possible and what not.

I don't want to tell that the approach is wrong, I just want to point
out possible problems we likely will come across, esp. if they hinder us
from getting an even better collaborating community.

Robert Kaiser