Skip to end of metadata
Go to start of metadata

When you work with a DVCS repository cloning, pushing, you are working with the entire repository and all of its history. In practice, once your repository gets larger than 500MB, you might start seeing issues.

To learn more about the size limitations Bitbucket uses see, What kind of limits do you have on repository/file/upload size?

Ideally, you should keep your repository size to 100MB or less. To give you an example, 94% of Bitbucket customers have repositories that are under 500MB. Both the Linux Kernel and Android are under 900MB.  In a perfect world, your ideal repository size should be less than or around 100MB.  This page contains the following topics:

Finding your repository size

To check the relative size of your repository in Bitbucket click Settings (1), which should open the Repository details (2) page, then look for the Size (3) line.

Git Repository Size from the Command Line

For Git, you can use the git count-objects -v command:

The size-pack value is the size of your repository when it is pushed to a remote server like Bitbucket. The size-pack value is in kilobytes.  So, in the above example the repository is not even 1 MB.  

Mercurial Repository Size from the Command Line

Mercurial does not provide a command specifically for find a repository repository size.  You can use the bundle command to generate a compression of your repository and then see the size of the file:

Deleting Files and other Maintenance

Deleting unused files is a good way to reduce repository size. Remember deleting a file does not remove it from history. It does reduce your repository at is current version.  Ever clone still contains the old file if you need to retrieve it.  When looking at files to delete, consider the following:

  • SQL dumps
  • Large media assets
  • Compiled versions of your applications
  • Third party libraries and dependencies (jars, dlls, gem, etc.)
  • Completely unneeded large files in history

Binary files are always candidates.  DVCS systems are not good candidates for storing binary files.  Consider hosting these on file hosting service such as Google Drive, Dropbox, or Carbonite.

You should also consider:

Split a Repository into Project Repositories

You can reduce your repository size by splitting a repository by code projects.  This requires that you understand how your projects  references each other. For example, if you have four projects that don't reference each other in one large repository, you split these up into four smaller repositories.  

For a procedure on splitting a repository, see Split a repository in two.


15 Comments

    1. Bitbucket doesn't support either of these extensions.  Vote up this issue by watching it.

  1. Anonymous

    What about storing media assets specifically source PSD design files? These are currently in SVN, on another server within the company (with various access issues due to firewalls). Ideally, we want these in GIT too, up on Bitbucket, so the entire team can access when required.

  2. Anonymous

    ok, so I found the answer.... not a good idea, GIT and binaries don't get along.

    https://confluence.atlassian.com/pages/viewpage.action?pageId=273877699

    "Keep in mind Bitbucket is a code hosting service not a file sharing service. If a lot of your files are extremely large or if your files are binaries or executables, you should understand Git or Mercurial will not work well with them. You'll find that even locally your repository is barely usable. Moreover, Bitbucket can't display diffs on binaries. For binary or executable storage, we recommend you look into file hosting services  such as DropBox, rsync, rsnapshot, rdiff-backup, and so forth."

  3. Anonymous

    So my repo on disk is 2GB, but in bitbucket it says 9+GB.  Can anyone explain this?

    1. The Bitbucket copy probably needs some cleaning up / garbage collection.  As Marcus Bertrand of Atlassian says in Re: What kind of limits do you have on repository/file/upload size?, "For the time being, please raise a support request to let us know to gc your repo."

  4. Is there a way to exclude files from past commits to reduce size? 

    1. Hey Gavin,

      Sorry it seems I missed this comment. You can use the process in Maintaining a Git Repository to remove files from old commits and then prune your history to reduce size.

      Hope that helps!

      Dan

      1. Thanks! Is there an equivalent article for Mercurial?

  5. Your instructions on finding repository size say "click settings" and show an icon at the lower-left, but I do not see this button in the web view of my repository. Is this a permissions issue? (I am on a team and did not create the repository). Or has the web GUI changed?

    1. A follow up: on a repository I created, I do see the settings button, and when I open it I see the repository size.

      IMO  being able to easily see the size of a repository even if you aren't the creator/admin would help teams have collective ownership of this basic maintenance aspect. Size should probably just be part of Overview as someone else suggested.

       

    2. Hey Christopher,

      Sorry bout that. I didn't get that screen shot updated. I've updated it to show where the settings are now. 

      I will let the team know your suggestion about moving repo size to the overview page. Feel free to also open a feature request issue and get it voted up. (smile)

      I hope this helped a bit.

      Happy coding,

      Dan

      1. I completely agree with Christopher Corbell that the repository size really belongs back on the Overview page (where it used to be) rather than hidden down in the Settings page where it is not obvious and not visible by everyone.  So, following your suggestion, I added this new issue.

         

        Issue #10522 NEW

        Move the repository size from the Settings page back to the Overview page.

        https://bitbucket.org/site/master/issue/10522/move-the-repository-size-from-the-settings