Import or convert code from an existing tool

 

To get your existing code into Bitbucket Cloud quickly from another hosting site or system, Bitbucket provides an importer to grab a repository. This importer works if you have your code in CodePlex, GitHub, Google Code, SourceForge, Subversion, or another Git/Mercurial-based hosting site. However, if your hosting site doesn't fall into one of these sources or you don't have a URL to enter, you can convert your code to Git or Mercurial.

This page

Import from a hosting site

You can import from popular code hosting sites via the Bitbucket importer. When you import code from an external Git or Mercurial repository, the importer simply creates a clone of the repository which is then hosted in Bitbucket.

The importer cannot convert Git repositories to Mercurial repositories or vice versa. 

  Importing a subversion repo?

Because Bitbucket doesn't host Subversion repositories, when you import from a Subversion repository, the importer:

  • exports a working copy of your trunk code base
  • builds a new DVCS repository
  • commits the entire working copy as a single DVCS changeset into the new repository on Bitbucket.

Bitbucket does not retain the history when importing code from Subversion. If you'd like to retain your Subversion revision history in Bitbucket, you must perform an offline synchronization. This may take a long time to complete and be CPU intensive, depending on the size of your repository, the number of revisions, branches and tags in your repository.

To import code do this:

  1. Choose Repositories > Import repository from the menu bar.
  2. Select the Source of the code you want to import.
  3. Depending on the Source, the system asks you to provide the following information:

    Source Information you must supply
    CodePlex URL, Project name, Repository type
    Git/GitHub URL, a Username/Password combination for private repositories that Require authorization
    Google Code URL, Project name, Repository type
    Mercurial URL, a Username/Password combination for private repositories that Require authorization
    SourceForge URL, Project name, Repository type
    Subversion URL, a Username/Password combination for private repositories that Require authorization
  4. Enter a Name for your new repository.
  5. Uncheck Private if you want the repository to be Public.
  6. Select a Language
  7. Click Issue tracking and/or Wiki if you want those features.
  8. Enter a Description and Website if you wish.
  9. Press Import.
  10. Clone your repository.

Converting from another system

To Git repositories: If you have a Subversion (SVN) repository that you'd like to convert to Git, refer to this guide from our Atlassian experts: Migrate to Git from SVN

To Mercurial repositories: So that you can convert a repository to Mercurial, it ships with a convert extension that supports conversion. For more information on the convert extension, refer to the Mercurial wiki. It allow you to convert from these systems:

  • Bazaar
  • CVS
  • Darcs
  • Perforce
  • RCS
  • Git
  • Subversion (refer to the following section for more information)

Convert from Subversion to Mercurial

Don't forget that you can import a working copy of your code (i.e. no history) from Subversion into Bitbucket Cloud. Return to the top for more explanation.

Option 1: The hgsubversion Extension – Recommended

The hgsubversion extension is a user-contributed extension, not distributed with Mercurial. We recommend this extension.  Please refer to the hgsubversion extension guide for download sites and usage instructions.

Option 2: Mercurial's convert extension

This extension is distributed with Mercurial. Refer to the documentation:

  • Enter hg convert without specifying any arguments to read the Mercurial manual.
  • Read about the ConvertExtension on the Mercurial Wiki.

Enabling the convert Extension

First of all, you must enable the convert extension that ships with Mercurial.

Edit your ~/.hgrc to look like this:

[extensions]
hgext.convert =

The convert command should now be available.

Subversion

While Subversion is currently used widely in all kinds of software development projects, more and more projects may want to convert to the DVCS paradigm.

For this example, we will be converting Graham Dumpleton's excellent mod_wsgi module, which is hosted on Google code.

For Subversion specifically, Mercurial is clever enough to recognize the trunk/branches/tags directory structure used ubiquitously. When you supply an URL for the repository, Mercurial will look for a trunk directory and if it exists, it will use it as the base. If it finds branches or tags it will also attempt to name branches and tags from that.

The Subversion URL for mod_wsgi is http:modwsgi.googlecode.com/svn. Lets begin by downloading the latest revision of the repository.

NB: You may also point Mercurial directly at the remote repository, although this is not as well supported as a local starting point. If you want to do this, you can skip this step.

$ svn co http://modwsgi.googlecode.com/svn/trunk mod_wsgi
A  mod_wsgi/mod_wsgi
A  mod_wsgi/mod_wsgi/configure
[...]
A  mod_wsgi/README
Checked out revision 929.

Now that we have the latest revision of mod_wsgi (aka HEAD), we have a place we can point Mercurial to. Mercurial will automatically pick up the correct settings and download the full history from the central repository.

$ hg convert mod_wsgi mod_wsgi_hg
initializing destination mod_wsgi_hg repository
scanning source...
sorting...
converting...
589 Initial directory structure.
588 Import code from existing private source code repository.
587 Make log message about signals being ignored a warning rather than error.
586 To be consistent with mod_rewrite, %{ENV} should also look in notes and
[...]
0 Fix issue with daemon mode where error logging when using ErrorLog in
updating tags

You're done! If you cd to the newly created mod_wsgi_hg directory, you will be entering a fully fledged, history-preserved Mercurial repository, consisting of the exact same files as the Subversion repository.

Now would be a good time to upload your repository to Bitbucket, so go ahead and create your repository on the Create Repository page.

Let's upload:

$ pwd
~/Work/mod_wsgi_hg
$ hg push http://bitbucket.org/jespern/mod_wsgi
pushing to http://bitbucket.org/jespern/mod_wsgi
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 589 changesets with 1021 changes to 7 files

The repository is now uploaded to our servers, and ready to use. Go check it out!

If this last step fails you might also need to run the hg update command before hg push as shown in the following example:

$ pwd
~/Work/mod_wsgi_hg
$ hg update
0 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ hg push http://bitbucket.org/jespern/mod_wsgi
pushing to http://bitbucket.org/jespern/mod_wsgi
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 589 changesets with 1021 changes to 7 files

The output might look different than this example, however the order of commands is the same.

Where do you go next?

Was this helpful?

Thanks for your feedback!

Why was this unhelpful?

Have a question about this article?

See questions about this article

Powered by Confluence and Scroll Viewport