On 09/29/2010 01:03 PM, Tuomo wrote: > Tomas Carnecky<tom<at> dbservice.com> writes: > > Which tools belong to the same class with Git? All repositories from pure distributed version control systems can be transformed into git repositories and git repos can be transformed into a repository of a pure distributed version control system, but not all repositories can do so without information loss since all dvcs systems store and represent things different and have (slightly) different capabilities. Octopus merges have been mentioned. I'm sure there are other things, such as the three different tag-types we have in git, that can't be properly represented by other scm systems. Exactly which those are and how it affects conversions from one system to another is something you seem to want to learn without actually doing the job of finding it out, and I doubt anyone on this list knows every detail you're looking for (although the complete information you're after might be available in scattered form among the population on this list). > > Is it possible to make a round-trip Mercurial->Git->Mercurial or > Git->Mercurial->Git without loss of any information? That depends. If the git repository has no octopus merges and no tags of a type that can't be represented in mercurial, I believe it should be possible. Try and find out. > I would expect that > Mercurial->Git->Mercurial might produce some differences if files have been > renamed or moved between directories, but other than that? > Possibly. Again though; Try and find out. > What particularly interests me is how the conversion handles unnamed Mercurial > branches? Probably as detached heads. There's nothing special with having commits with no refs attached to them in git. > 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? > So now we get to a proper use-case. You want to convert a Synergy repository to something else, and you've been looking at mercurial and git. So let me ask you a question; What have you done so far to find out the answer to the questions you're looking for, apart from asking here how a theoretical scenario would pan out? -- Andreas Ericsson andreas.ericsson@xxxxxx OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace. -- 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