Re: What's cooking in git.git (Jan 2013, #08; Tue, 22)

[John Keeping <john@keeping.me.uk>]

On Tue, Jan 22, 2013 at 02:44:48PM -0800, Junio C Hamano wrote:
> * jc/cvsimport-upgrade (2013-01-14) 8 commits
>  - t9600: adjust for new cvsimport
>  - t9600: further prepare for sharing
>  - cvsimport-3: add a sample test
>  - cvsimport: make tests reusable for cvsimport-3
>  - cvsimport: start adding cvsps 3.x support
>  - cvsimport: introduce a version-switch wrapper
>  - cvsimport: allow setting a custom cvsps (2.x) program name
>  - Makefile: add description on PERL/PYTHON_PATH
> 
>  The most important part of this series is the addition of the new
>  cvsimport by Eric Raymond that works with cvsps 3.x.  Given some
>  distros have inertia to be conservative, Git with cvsimport that
>  does not work with both 3.x will block adoption of cvsps 3.x by
>  them, and shipping Git with cvsimport that does not work with cvsps
>  2.x will block such a version of Git, so we'll do the proven "both
>  old and new are available, but we aim to deprecate and remove the
>  old one in due time" strategy that we used successfully in the
>  past.
> 
>  Will merge to 'next'.

Would you mind holding off on this?  As it stands there are a couple of
issues with the cvsimport-3 script including:

    * It doesn't read any configuration from "git config" as
      git-cvsimport-2 does.

    * Incremental import is copmletely broken - it needs to pass "-i" to
      cvsps-3 and even then timestamp handling is completely broken.

I have fixes for these that are nearly ready, but to fully fix the
incremental import issue I'll need to persuade ESR to take a patch which
lets us feed cvsps-3 a mapping from branch names to last commit times.

I suspect people are already used to the ways in which cvsimport-2 is
broken so I think we should take a bit more time to get this right with
cvsimport-3, especially since the people most likely to be using this
will be those regularly updating from a CVS repository with incremental
updates.


John