Martin Langhoff wrote: > On 9/14/06, Markus Schiltknecht <markus@xxxxxxxxxx> wrote: >> Martin Langhoff wrote: >> > On 9/14/06, Jon Smirl <jonsmirl@xxxxxxxxx> wrote: >> >> Let's copy the git list too and maybe we can come up with one importer >> >> for everyone. >> > >> > It's a really good idea. cvsps has been for a while a (limited, buggy) >> > attempt at that. One thing that bothers me in the cvs2svn algorithm is >> > that is not stable in its decisions about where the branching point is >> > -- run the import twice at different times and it may tell you that >> > the branching point has moved. >> >> Huh? Really? Why is that? I don't see reasons for such a thing happening >> when studying the algorithm. >> >> For sure the proposed dependency-resolving algorithm which does not rely >> on timestamps does not have that problem. > > 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? 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. And the real trick is that things can be done in CVS (e.g., line-end changes, manual copying of files in the repo) that (a) are unversioned and (b) have retroactive effects that go arbitrarily far back in time. This is the reason that I am pessimistic that incremental conversion will ever work robustly. Michael - 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