Re: cvsimport still not working with cvsnt

> Hello Guy,
>
>
> On 12/20/10 15:36, Jonathan Nieder wrote:
>> (+cc: Emil, some cvsimport people)
>>
>> Guy Rouillier wrote:
>
> Sometimes, on some particularly nasty CVS repos, I noticed better
> results when using http://cvs2svn.tigris.org
>
>>> I'm going to try sending this blind, as the mailing list has sent me
>>> the promised authorization key after 24 hrs.
>>
>> No problem.  Actually a subscription is not required --- the
>> convention on this list is to always reply-to-all.
>>
>>> I finally found the problems, both of which were reported in 2008
>>> here:
>>>
>>> http://kerneltrap.org/mailarchive/git/2008/3/13/1157364
>>
>> Seems to have received no replies[1].
>
> I don't remember why, but that patch didn't get enough interest
>
>>> I do see one possible issue with the supplied modifications.  At
>>> work, we upgraded from CVS to CVSNT.  So, my home directory has both
>>> .cvspass (from the original CVS) and .cvs/cvspass (after the
>>> conversion to CVSNT.)  Sloppy housekeeping on my part, I admit, but
>>> probably not uncommon.  The supplied patch would pick up the
>>> original CVS file and would fail.  (BTW, this is true only of the
>>> git-cvsimport.perl script itself; cvsps must shell out to the
>>> installed CVS client (in my case, cvsnt), because when I invoked
>>> that manually, it worked.)
>>>
>>> So, I would advise checking to see if both files exist, and if so
>>> exit with an error.  Unless cvsimport wants to get real fancy and
>>> shell out to the installed cvs client to try to figure out what is
>>> installed, there is no way to tell which cvspass file is actively
>>> being used.  I don't recommend trying to figure this out, as the
>>> user's intent is unclear.
>>
>> Thanks, sounds sane to me.  Care to write a patch?
>
> If you care enough about this scenario, how about search for the
> relevant<CVSROOT, password>  in both files. If you find just one pair or
> if you find a pair in both files and they are "equal" then just use it.
> If you find two pairs, one in each file, use the one from the file with
> a newer modified time-stamp. In a migration scenario such as this, you'd
> imaging the "old" file will get stale after a while. Not perfect, but
> some informational messages in case of a duplicate would help the user
> clarify their intentions
>
> Additionally/Alternatively just add a command line parameter to allow
> the user to explicitly specify a cvspass file