Re: git copies of cvs modules available

[Michal Suchanek <hramrach%centrum.cz@localhost>]

2010/1/11 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."
>

I see multiple issues here. It is not surprising that like cvs git
requires a service of its own to work properly, and it is not
surprising that the current vcs admins do not want to run multiple
such service as it means more work for them and perhaps too much
server load as well.

It is also not surprising that git does not offer some features cvs
does. The underlying infrastructure is vastly different so it offers
many new and useful features at the cost of making some other things
more difficult or impossible with the current state of the available
tools.

It is also not surprising that conversion from CVS to git has its
problems. It seems that every project doing such conversion faces
issues, and the larger the repository the more issues there are.

There is one point that many people in this discussion seem to miss.
If the cvs repository was put in such state that it *can* be
automatically converted to other vcs then people can create their own
mirrors off the netbsde.org servers. You can get the features of cvs,
git, and likely any other vcs all at once without additional load on
the netbsd infrastructure.

The problem is that this requires not only significant one time work
of "fixing" the repository but ongoing commitment from people who have
cvs write access to keep it in this state. But perhaps it is too much
to ask cvs fans to not spoil the fun for git fans.

Thanks

Michal