On Thu, May 28, 2009 at 12:10 PM, Markus Wanner <markus@bluegap.ch> wrote:
> Hi,
>
> Quoting "Robert Haas" <robertmhaas@gmail.com>:
>>
>> My understanding is that the histories of some of the branches we have
>> now are flat-out wrong.
>
> AFAIU only the latest revisions of the branches have been compared. Keeping
> history and future in mind, that's not telling much, IMO. In my experience,
> there's much more wrong with converted CVS repositories - the latest
> revisions are often just the tip of the iceberg. Depending on your
> definition of "wrong", of course.
That's not the best news I've had today...
>> I don't have a problem keeping those
>> alongside the corrected history for ease of rebasing and porting
>> commits, but I don't want to punt the problem of figuring out what the
>> one, true, and correct history is to the user.
>
> Understood and agreed. (In a distributed VCS, you cannot "delete" history by
> definition, because every user is free to keep his version).
>
> However, I'm pretty certain this is not the last "flat-out wrong" thing we
> find in the CVS or in the converted git repository. Going to fix and rebase
> every time might be pretty annoying and time consuming. Thus alternatives
> like those mentioned by Aidan sound interesting to me.
To me they sound complex and inconvenient. I guess I'm kind of
mystified by why we can't make this work reliably. Other than the
"broken tags" issue we've discussed, it seems like the only real issue
should be how to group changes to different files into a single
commit. Once you do that, you should be able to construct a
well-defined, total function f : <cvs-file, cvs-revision> -> <git
commit> which is surjective on the space of git commits. In fact it
might be a good idea to explicitly construct this mapping and drop it
into a database table somewhere so that people can sanity check it as
much as they wish. Why is this harder than I think it is?
...Robert
