Re: cvsimport still not working with cvsnt

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2/20/2011 2:21 AM, Junio C Hamano wrote:
> Guy Rouillier <guyr@xxxxxxxxxxxxx> writes:
> 
>> The two clients use a different delimiter to separate the CVS
>> repository name from the user password.  The original CVS
>> client separates the two entries with a space character, while
>> CVSNT separates them with an equal (=) character.  Hence,
>> the regular expression used to split these two tokens is
>> altered to accept either delimiter.
> 
> That sounds like a wrong approach.  If there are two clients, one reads
> from one location with one syntax, and the other one reads from another
> different location with a different syntax, shouldn't the code using the
> original syntax when reading the original file, and the other syntax when
> reading the file for the other client?

...

> In practice, I would imagine that the cvsroot part wouldn't contain an
> equal sign, so this looser regexp would not hurt in the real life, but it
> does feel yucky.

Well, this is the important point. I did think of these aspects when
writing the code.  Sure, writing more precise code is possible, but the
results are the same in either case.  If you look back at the version I
wrote in response to Emil's post, I did have two entirely separate 
sections for CVS and CVSNT, and I used only one delimiter in each.  
Martin then suggested I combine the two sections into one, so while
following that suggestion I had to alter the regular expression.

> Here is a totally untested patch.  I think the original code used
> $pass="A" as a fall-back when it didn't find any password entry, and I
> tried to retain that instead of dying.  Also this does not error out if
> you merely have two cvspass files, as long as you do not have the wanted
> entry for both of them.

I'll take a look at the patch later this week when I have some time.  I
purposely took out the code the set the password to "A" if the CVS
repository is not located in the password file.  I was surprised to
see that in the original code.  I can't think of any situation 
where silently making up a password is a good idea.

Finally, after our last round of discussions, I thought we all agreed
not to try to do any matching on the contents of the two password files.
I originally implemented a comparison of the contents of the two files,
but you pointed out there are many possible permutations involving
entries found in both files.  So I went back to my earlier approach
of just erroring out if both files are found.

-- 
Guy Rouillier
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]