Tomas Carnecky <tom <at> dbservice.com> writes: > fast-import/export (man git-fast-export/import) seems to be the future. > Git provides excellent support for it and other SCMs are adopting it as > well. And then there are custom written conversion tools, just take a > look at [1] to see which ones are available. > > (shameless plug: just this weekend I started collecting the various fast > import/export tools and made a webpage about it: > http://caurea.org/fast-export-import/. It's far from complete though. > And if you know any tools that perform better than those I've listed, > I'd be glade to update the page). Last time I was looking for conversions between source control tools, I could not find any (but my attempt may have been a bit limited). I am very happy to see that there is now not only a plethora of point-to-point conversion tools, but a common exchange format. It means that the field of source control is finally maturing, finding common concepts that most agree on. However, the scanty documentation for the tools does not answer my question. I'll try to formulate it again. You can move history from SCCS to RCS without losing anything, but you cannot move from RCS to SCCS, because SCCS does not handle sub-branches. You can move from RCS to CVS, but since RCS does not record evolutionary relationships between tags, the result does not record the history in the manner we'd expect in CVS. You can provide additional data to the conversion, but that additional data cannot be automatically deduced by any general algorithm. You can move stuff from CVS to RCS, but you lose the evolution of the whole configuration. So, SCCS, RCS and CVS all belong to a different class. Only the latest tools have enough in common that one can find enough of information to make a full transfer of history without loss of data that can be deduced by automatic means if a back-conversion is desired. Which tools belong to the same class with Git? Strictly speaking, I am talking about conversions that do not require us to inject any additional data, conversions that are fully automatic. The page http://wiki.darcs.net/DarcsGit mentions that Darcs->Git->Darcs roundtrip loses no information (but also notes that the tool is nowadays broken and needs fixing), but the same is not true for the other direction. That is the kind of information I am looking for. Is it possible to make a round-trip Mercurial->Git->Mercurial or Git->Mercurial->Git without loss of any information? I would expect that Mercurial->Git->Mercurial might produce some differences if files have been renamed or moved between directories, but other than that? What particularly interests me is how the conversion handles unnamed Mercurial branches? I am asking this because at work, I had to ponder once if it would be possible to transfer histories from Synergy (ex Continuus) to some other tool, and found it very difficult to imagine how to create named branches from the version DAGs Synergy uses. You can never be sure if a new version is a successor of its predecessor on the same branch or the first version on a sub.branch, because Synergy doesn't treat them any differently. users often try to organize the branches in ways compatible with other tools, but since Synergy has no way of enforcing any of these methods, there is no guarantee of consistency. The worst-case scenario is that every single version is its own branch. So, I really would like to know how the unnamed branches from Mercurial are transferred to named branches in Git? -- 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