Re: I have end-of-lifed cvsps

> On Thu, Dec 19, 2013 at 10:31 AM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
>> On 12/19/2013 02:11 AM, Johan Herland wrote:
>>> On Thu, Dec 19, 2013 at 12:44 AM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
>>>> A correct incremental converter could be done (as long as the CVS users
>>>> don't literally change history retroactively) but it would be a lot of work.
>>>
>>> Although I agree with that sentence as it is stated, I also believe
>>> that the parenthesized condition rules out a _majority_ of CVS repo of
>>> non-trivial size/history. So even though a correct incremental
>>> converter could be built, it would be pretty much useless if it did
>>> not gracefully handle rewritten history. And in the face of rewritten
>>> history it becomes pretty much impossible to define what a "correct"
>>> conversion should even look like (not to mention the difficulty of
>>> actually implementing that converter...).
>>
>> A correct conversion would, conceptually, take a diff between the old
>> CVS history and the new CVS history (I'm talking about the history as a
>> whole, not a diff between two changesets), figure out what had changed,
>> and then figure out what Git commits to make to effect the same
>> conceptual changes in Git-land.
>>
>> This means that the final Git history would have to depend not only on
>> the current entirety of the CVS history, but also on what the CVS
>> history *was* during previous incremental imports and how the tool chose
>> to represent that history in Git the previous rounds.
>>
>> There is a tradeoff here.  The smarter the tool is, the fewer
>> restrictions would have to be made on what people can do in CVS.  For
>> example, it wouldn't be unreasonable to impose a rule that people are
>> not allowed to move files within the CVS repository (e.g., to fake
>> move-file-with-history) after the CVS <-> Git bridge is in use.  (Abuses
>> of the history that occurred *before* the first incremental conversion,
>> on the other hand, wouldn't be a problem.)  If the user of the
>> incremental tool has *no* influence on how his colleagues use CVS, then
>> the tool would have to be very smart and/or the user would might
>> sometimes be forced to do another from-scratch conversion.
> 
> Agreed, but I find it quite ugly how the git history will end up
> different depending on _when_ the incremental conversion is run. It
> means that it will be impossible for two users to create the same Git
> repo (matching SHA1s), unless they carefully synchronize all of their
> conversion runs

>>> My point here is that people will use whatever available tools they
>>> have to solve whatever problems they are currently having. And when
>>> CVS is your tool, you will sooner or later end up with a "solution"
>>> that irrevocably rewrites your CVS history.
>>
>> Yes, but I maintain that an incremental importer could keep a Git
>> history that is consistent with the CVS history in the sense that:
>>
>> 1. the result of checking out any branch or tag, right after a run of
>> the importer, gives the same results as checking the same branch or tag
>> out of CVS.
>>
>> 2. the Git history from one run is added to (never rewritten) by the
>> next run.
> 
> Yes, and even my simplest/fastest possible converter described above
> can meet those criteria. After that, it really becomes a question of
> _how_much_ CVS history you want to retain in your incremental import.

> I have described the two extremes above. Interestingly, _both_ of
> those extremes would look quite different from the
> whole-history-gone-incremental converters represented by cvs2git and
> cvs-fast-export, and _both_ of the extremes would probably also
> provide a converted result quite a bit faster than anything in between
> (one by virtue of depending on a single "cvs update" command, and the
> other by monitoring the CVS server and performing the conversion to
> Git in real time).