On 09/29/2010 03:03 PM, Tuomo wrote:
> Andreas Ericsson<ae<at> op5.se> writes:
>
>>
>> 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.
>
> Nah, I am not working with Synergy. I referred to an earlier encounter with it.
>
> Right now, I am stuck with ClearCase. Most of the projects have been using base
> ClearCase, not UCM, and it means that there is no realistic way to transfer the
> histories anywhere. It can be tried, sure, but who would really want to do it?
> What I am looking for is tools that I can recommend to the projects, tools
> that are available to them, and will not pose a threat in being non-convertible,
> tools that would allow the projects to later make another decision, and not get
> stuck with the tool they choose now.
>
In general, it's easier if they decide to change to a distributed version control
system such as git, mercurial or bazaar, since those generally have a much better
data model than centralized systems where you can get away with ugly workarounds
much easier.
Workable conversions are possible between very nearly every scm out there and
whatever you want. It's not necessarily possible to convert back in a way that
makes it look as if you'd used the original scm all the time, but it's (almost)
always possible to create a new repository that is obviously functional and
contains all or most of the relevant history. Such conversions generally take
quite a while for projects with a large history though, so it's not something
you'd ponder doing twice a week.
Most larger projects that have switched have done so with the intention of
using the switched-to system for at least the foreseeable future and have thus
done proper research into what that system has to offer and then made the
decision based on featureset, data model and usability of the available
systems. If you make the decision based on how easy it is to switch away
from the system you choose, you're bound to end up having to do just that
sooner or later.
Either way, very nearly every project in the world who in the past 3 years
have gone looking for a better version control system has gone with one
of the two major distributed systems, git and mercurial. Conversion between
those two is relatively quick and painless and produces working repositories
in both directions, even if git -> hg -> git doesn't necessarily produce a
repository identical to the one you started out with.
>> 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?
>
> Fair enough. I am looking for documentation, and advice on how to find worthy
> sources, before delving into trying out something for no good reason.
> But, at the same time, I wish to have a look-see on what the general status
> is right now. If there is no summary of it available, then apparently I have to
> make it myself. But I would hate to find out afterward that someone had in fact
> done it already. Tomas Carnecky's list is a good start.
>
You're looking at the wrong criteria for switching vcs. If the main goal is to
be able to convert the target repository back into the original one, you're up
for disappointment in what you'll find. None of the conversion tools destroy
the original repository though, so you can experiment with any one you like.
Some general truths that might aid you though:
git has the best fast-{import,export} support. Not surprising since the format
was engineered by the brilliant minds we're fortunate to have on the git list.
Conversion between git and other distributed version control systems produce
working repositories in a quick and painfree fashion.
It is usually impossible to convert from one repository format to the other
and back again in such a fashion that the resulting repository is identical
to the one you started with.
It is almost always possible to create a working repository of any kind from
a repository type that has a fast-export tool.
Writing a fast-import tool is not exactly rocket science, although it could
get timeconsuming if the target vcs is limited in capabilities and many
workarounds are necessary.
Most people don't switch to a vcs with fewer capabilities than the one they're
already using, so the previous point is mostly academic.
--
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