From: Martin Langhoff Date: Thu, 14 Sep 2006 04:40:47 GMT Subject: Re: cvs import Message-ID: <46a038f90609132140v10118b53q8f8001bcf575263d@mail.gmail.com> In-Reply-To: <4508D7DA.8000302@alum.mit.edu> On 9/14/06, Michael Haggerty wrote: > > IIRC, it places branch tags as late as possible. I haven't looked at > > it in detail, but an import immediately after the first commit against > > the branch may yield a different branchpoint from the same import done > > a bit later. > > This is correct. And IMO it makes sense from the standpoint of an > all-at-once conversion. > > But I was under the impression that this wouldn't matter for > content-indexed-based SCMs. The content of all possible branching > points is identical, and therefore from your point of view the topology > should be the same, no? Exactly. But if you shift the branching point to later, two things change - it is possible that (in some corner cases) the content itself changes as the branching point could end up being moved a couple of commits "later". one of the downsides of cvs not being atomic. - even if the content does not change, rearranging of history in git is a no-no. git relies on history being read-only 100% > But aside from this point, I think an intrinsic part of implementing > incremental conversion is "convert the subsequent changes to the CVS > repository *subject to the constraints* imposed by decisions made in > earlier conversion runs. Yes, and that's a fundamental change in the algorithm. That's exactly why I mentioned it in this thread ;-) Any incremental importer has to make up some parts of history, and then remember what it has made up. So part of the process becomes - figure our history on top of the history we already parsed - check whether the cvs repo now has any 'new' history that affects already-parsed history negatively, and report those as errors hmmmmmm. > This is the reason that I am pessimistic > that incremental conversion will ever work robustly. We all are :) But for a repo that doesn't go through direct tampering, we can improve the algorithm to be more stable. martin