Re: git copies of cvs modules available

[Alistair Crooks <agc%pkgsrc.org@localhost>]

On Sun, Jan 10, 2010 at 04:40:54PM -0500, Arnaud Lacombe wrote:
> > Similarly, if the
> > cvs-to-git import scripts weren't stupid about file revisions and RCS
> > keywords...
> >
> This is because all tools live on top of cvs(1) output, rather than
> directly parsing the ,v files.
> 
> Stupid question: has it ever been thought to "restart from the
> beginning", ie keeping a "legacy" tree and re-import everything in a
> more "git-based" workflow, ala Android's repo or git' submodules ? In
> particular having separate tree for external project (like say
> src/gnu/dist/, src/external/ and crypto/). These represent 3/5 of the
> tree, and are barely ever touched by anyone but their respective
> maintainers. Histories of the said submodules may even be kept using
> proper filters.

So the conversation has gone something like this...

1. this is a git repo of the NetBSD src repo (thanks, Petra)
2. performance is not great
3. that's because the "correct" protocol is not in use
4. Using the "correct" protocol puts much more load on the servers;
more than we want at the current time

5. Also, the git pack files are too large
6. Make them smaller then
7. They can't be made smaller at the current time as that would add
more load; more than we want at the current time

8. Also RCS keyword expansion is evil
9. Are the skies blue in your homeworld?
10. No really, they're evil, unnecessary, and unwanted
11. Ummm, this is new - and I, for one, would like keyword expansion
12. There is a plugin module to do this, it's unsupported because
what you're doing is wrong

13.  And so to today's - we should kick out history from the repo and
start again
14. I, for one, quite like having history available. After all, those
who don't learn from history are doomed to repeat it

To summarise the above - I see a lot of encouragement from git fans to
move to something good, useful, and modern, where branching is close
to free, and offline commits are first class citizens.  And it would
be nice to have them too.  But the price for moving to git is high,
and causes relapses and regressions in other behaviour.  The previous
conversations (see above) would also seem to indicate that git is not
the right tool for NetBSD (gasp!).  Instead of dismissing these
relapses and regressions in git, it would be great to see some buy-in
from these people that "yes, this *is* a problem", and then we could
start planning to address the issues, and use it in anger.

Until that time, I'd have to say "it obviously works for some people,
and that's great - I wish you luck, but please be aware that until you
seek to address my issues, it won't work for me."

Regards,
Alistair