git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andreas Ericsson <ae@op5.se>
To: Tuomo <tuo.tie@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: Another way to compare tools: is it possible to transfer full history?
Date: Wed, 29 Sep 2010 15:28:03 +0200	[thread overview]
Message-ID: <4CA33EE3.3090202@op5.se> (raw)
In-Reply-To: <loom.20100929T145158-59@post.gmane.org>

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@op5.se
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.

  reply	other threads:[~2010-09-29 13:28 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-28 13:44 Another way to compare tools: is it possible to transfer full history? Tuomo
2010-09-28 14:53 ` Tomas Carnecky
2010-09-28 15:48   ` Michael Haggerty
2010-09-28 20:48   ` Jonathan Nieder
2010-09-28 20:55     ` Sverre Rabbelier
2010-09-29 11:03   ` Tuomo
2010-09-29 11:19     ` Andreas Ericsson
2010-09-29 13:03       ` Tuomo
2010-09-29 13:28         ` Andreas Ericsson [this message]
2010-09-29 13:53           ` Tuomo
2010-09-29 14:00             ` Bruce Stephens

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4CA33EE3.3090202@op5.se \
    --to=ae@op5.se \
    --cc=git@vger.kernel.org \
    --cc=tuo.tie@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).