Re: git-cvsimport-3 and incremental imports

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

 



Jonathan Nieder <jrnieder@xxxxxxxxx> writes:

> Eric S. Raymond wrote:
>
>> You get to integrate this.  I think the transition strategy Junio
>> has chosen is seriously mistaken, leading to unnecessary grief for users
>> who will be fooled into thinking it's OK to still use cvsps-2.x.
>
> So our choices are:
>
>  a. support current users, offend ESR, don't benefit from ESR
>     improvements
>
>  b. give up on current users, please ESR, benefit from ESR
>     improvements
>
>  c. some option yet undiscovered
>
> In that case, (c) sounds like our best bet.  Do I understand
> correctly?
>
> Sigh,
> Jonathan

Isn't (c) is to just build on cvsimport-2 and cvsimport-3 combo?

If Eric does not want to get involved in cvsimport-2 (and cvsps2),
that is perfectly fine.  We have the beginning of cvsimport-3 code
that was released with Sign-off, and as long as cvsps3 produces a
"more corrrect" output stream (either traditional cvsps2 style or as
a fast-import stream) than cvsps2 conversion describes, cvsimport-3
can get the full benefit of his work, no?

I do not think that Eric will be the only person who understands
cvsps3 output who can fix bugs that may potentially still exist in
cvsimport-3 code [*1*].

We live in real world, and distro inertia makes it likely that a new
version of git that does not work for people who have been happy
with cvsps2 will get resistance from them, when they do not trust
the 0.x releases of a new piece of software "cvsps3" that happens to
have a name similar to what they have been shipping, i.e. "cvsps2".
Shipping such a crippled Git will not be an effective way to promote
adoption of "cvsps3".

[Footnote]

*1* This of course assumes Eric's two major claims are true, that
is, (1) cvsimport-3 is already mature and better than cvsimport-2,
and (2) the code is so simple that it does not even need its own
tests as long as the front-end conversion that happens at the cvsps3
end is tested well.  Choosing b. will have to assume them to be true
anyway, so I do not think it is a big loss to rely on the same
assumptions and choose b. from our point of view.




--
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]