Re: Proposal of reposurgeon applied to cvs2git

[Daniel J S. <dan...@ie...>]

On 11/02/2017 02:08 PM, Eric S. Raymond wrote:
> Daniel J Sebald <dan...@ie...>:
>> I'm certain HBB would have no problems running the "construct_cvs2git_repo"
>> script, so I would propose that HBB and I take a look at that cvs2git result
>> over the course of a day (I'm already pretty confident) and declare "It's a
>> go", then Eric apply reposurgeon, restoring the items I removed from
>> ./reconvert that are of significance, then post the BETA release to
>> sourceforge.  If everyone's then happy with the beta version, we'd be done.
> 
> Sorry, not interested in going through yet another round of
> complications - unless you think you have fixes or at least good bug
> characterizations for cvs-fast-export or reposurgeon.  Those I'd take.
> 
> For me, messing with cvs2git has negative value.  I can't use it in my
> standard conversion workflow, it makes the refinement cycles too slow.

I wrote the script so that cvs2git is run once and the refinement cycle 
is running reposurgeon on that git repo.  Perhaps things slow down 
because the source is a git repo as opposed to a cvs repo.  I just 
finished a script that loops through every main CVS version name and 
diffs against the cvs2git+reposurgeon version.  Things check out well. 
You did write git support into reposurgeon, and the combo does look nice.


> At some point, somebody in your crew is going to have to decide you'll
> stop screwing with the conversion and cut over to using it.  You've
> long since overshot the amount of effort Ethan and I think is
> appropriate.
> 
> Remember,
> 
>     wget http://www.catb.org/~esr/gnuplot-conversion.tar.gz
> 
> The last change I made was to clean up and parametrize the repository-nuker
> script.  After three weeks of this I think it's time for me to bow out and
> pay attention to projects  I've been neglecting. You guys gave a deadline
> to meet and a policy decision to make.

Sorry Eric, I understand the frustration.  My view, though, is that the 
source of time involved here is the fact cvs-fast-export results 
required so much manual grafting with reposurgeon.  Had I known that was 
involved at the start, I would have suggested a pause.  I myself had to 
dig through a lot of repo-conversions to assist in finding the correct 
branch-points.  That said, my interest is balancing best conversion with 
reasonable effort.

Ethan and HBB make the call here, as I see it.

Thanks for your effort,

Dan