Re: git copies of cvs modules available

[Curt Sampson <cjs%netbsd.org@localhost>]

On 2010-01-11 19:08 +0100 (Mon), S.P.Zeidler wrote:

> Thus wrote Michal Suchanek (hramrach%centrum.cz@localhost):
> 
> > It is not surprising that like cvs git
> > requires a service of its own to work properly,
> 
> UNlike cvs, unless you want to name ssh 'a service of its own'.

Perhaps he should have appended, "when not being used over ssh" to that
statement. Both cvs and git work just fine without anything special
installed if the user has shell access via ssh to the host that contains
the repository. Both also need a special service and protocol for users
that do not have shell access to that host.

> Work for me is not the point (unless it's pointless work :).
> The current git repo is situated on the ftp server, not on any cvs
> server. The frequent updates of the git repo are sufficient extra load
> already for that machine.

Right. So it seems the solution, should we desire it enough, is simple:
add another server. That server would run git protocol and interfere
with nothing else. We can continue to do the git repo updates on the ftp
server (pushing them to the git server) or move them, as we wish.

Unless anybody has any serious objections to somebody doing this, the
issue is now just finding the volunteers (one with a host, the same one
or another to do the sysadmin) to step up.

> The git conversion has systematic errors (see the "keyword expansion"
> topic) with the automatic conversion tools available, and no change
> whatsoever in cvs will fix that, because it is not cvs that is in error
> here, but the conversion tools available.

Actually, that can be fixed in the conversion tool relatively easily.
The bigger problem is, how do we keep doing keyword expansion if we
switch to git?

These days, my preference would be to kill it. It makes me nervous that
a checkout of a particular revision is not what's in the repository for
that particular revision, but instead a modified copy whose particular
modifications may change when the VCS software changes.

> Note that above all other concerns, a master repository must be stable
> enough not to turn itself into a heap of bit garbage the first time
> there is some external trouble....

Again, are you claiming that, say, Git is less stable than CVS in this
sense? I find it to be much more stable.

> ...and it also ought to support the way NetBSD development works.

Not necessarially. It needs to support a development style to which
we're willing to move. There's no rule that says the NetBSD project must
never change its development style. And we have happily changed it in
the past. (Compare how I came in to the current process for bringing in
a new developer.)

> Last, making life easier for people without commit access is a welcome
> side effect (and 3/4 of the reason we bother keeping the git conversion
> running at present), but not the scope of tech-repository.

If that's not in the scope of tech-repository, where should we be
discussing this?

On 2010-01-11 19:56 +0100 (Mon), S.P.Zeidler wrote:

> Everything uses cvsps, and that is just not good enough.

Well, you mean that at the current time the general consensus is that
it's not good enough. That could change. For example, enough of us might
one day decide that doing a less perfect import into Git is good enough
if we keep a copy of the old CVS repo around for historical purposes as
well. It just depends on the trade-offs that people are willing to make,
and those change from time to time.

cjs
-- 
Curt Sampson         <cjs%cynic.net@localhost>         +81 90 7737 2974
             http://www.starling-software.com
The power of accurate observation is commonly called cynicism
by those who have not got it.    --George Bernard Shaw