> - the git architecture is admirably suited to an _untrusted_ central
> server, ie exactly the SourceForge kind of setup. I realize that the
Definitely. And beyond that too. Using SF for CVS means that when SF's
CVS service is down (often enough) you can't commit (or even fscking
diff) until they are back up. Every single damn operation does a
roundtrip. This also means a huge load on their servers.
I'm sure SF will be glad to see CVS fall our of favour.
> Yes, developers can just merge with each other directly
I take it that you mean an exchange of patches that does not depend on
having public repos. What are the mechanisms available on that front,
other than patchbombs?
> This is _exactly_ where something like SF really ends up being helpful.
> It's a _hosting_ service, and git is eminently suitable to being
Not sure whether SF is offering rsync, but they do support hosting of
arbitrarty data -- and a project using GIT can use that to host
several developer trees . It'd be nice if SF offered gitweb and
similar niceties. As my usage of GIT increases, I may add support for
it on Eduforge.org
If I had more (hw/time) resources I'd do the git proxying of CVS
projects, but that's huge.
> And so I'd be thrilled to have some site like SF support it.
Eduforge's charter is to host education-related projects, so that's
not a free-for-all-comers, but I'm considering git support, as our
usage of git is growing.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html