PageRenderTime 49ms CodeModel.GetById 22ms RepoModel.GetById 1ms app.codeStats 0ms

/2008/9/14/bitbucket-is-no-bit-bucket.rst

https://github.com/dag/lucumr
ReStructuredText | 105 lines | 92 code | 13 blank | 0 comment | 0 complexity | 63f8c8583a4f365870ca09c231c6bc26 MD5 | raw file
  1. public: yes
  2. tags: [hg, bitbucket]
  3. summary: |
  4. Old article about why I love bitbucket.
  5. Bitbucket is no Bit bucket
  6. ==========================
  7. When `github <http://github.com/>`_ appeared on the internets for the
  8. first time, there was a short period of time when I saw the admins of
  9. that sitehappy github users [See `the follow up to this post
  10. </2008/9/20/apologies-to-github/>`_
  11. for an explanation] jump into many IRC channels of projects that were
  12. using git already to switch to github for hosting. Personally for me
  13. that was alarming because after a while it appered that git without the
  14. hub was no accepted option any more for open source projects.
  15. Ever since `we <http://pocoo.org/>`_'re running our own server I think
  16. nobody of us ever regretted to host our personal development tools such
  17. as subversion (or now mercurial), trac, irc bots and a lot more. Root
  18. servers have become pretty cheap (especially in Germany) and
  19. debian/ubuntu make server administration a charm.
  20. It really hit me hard when I noticed that people are sacrificing the
  21. distributed nature of git and switch to a central hosting location, even
  22. though they have their own server infrastructure (I'm looking at you,
  23. rails team). Git was designed to not be dependent on a central server
  24. and it just doesn't feel right in my eye to force people to switch to a
  25. cental hosting platform because it provides things you would be missing
  26. otherwise (branchviewers, fork overviews or something).
  27. This was pretty much the reason why I wasn't interested that much in
  28. `bitbucket <http://bitbucket.org/>`_ either. I found it a well done
  29. version of hgweb with very fair hosting plans with builtin wiki and bug
  30. tracker. Basically the thing I would prefer over Google's code hosting
  31. (I'm not a big fan of subversion any more you know).
  32. A few days ago however I signed up on bitbucket so that I could push to
  33. the `dozer <http://www.bitbucket.org/bbangert/dozer/>`_ repository. A
  34. few hours later jespern queried me on freenode and welcomed me to
  35. bitbucket. First I was afraid the conversion that started would evolve
  36. into a github like "switch to our service, you won't regret it"
  37. conversion but it was actually nothing of that sort. That fear out of
  38. the way I decided to try mirroring some of the pocoo repositories to
  39. bitbucket (because well, you know: we do have some server outages from
  40. time to time and a mirror is never a bad idea). And what should I say?
  41. It's a really, really nice way to host open source project. I won't
  42. compare it to github here which is very similar except that it uses git
  43. rather than mercurial and doesn't offer a bug tracker and different
  44. plans, but to google code which is a very popular project hosting
  45. platform these days.
  46. The big advantage over Google code is obviously that you are using
  47. mercurial rather than Subversion. While a closed source project usually
  48. has a known number of developers that all have access to the code an
  49. open source project usually deals with code from constributors that
  50. don't have access to the code. So I personally think that this alone
  51. makes Google code look bad for open source projects.
  52. Both Google code and bitbucket are providing a wiki and a bug tracker.
  53. The wiki in Google code is implemented on top of Subversion which is not
  54. really that interesting to know but it of course gives you the
  55. possibility to access the data locally too. Bitbucket does something
  56. very similar and stores the wiki pages in a separate mercurial
  57. repository. Especially nice is that the wiki syntax is the well
  58. established creole syntax which makes processing of the wiki pages
  59. locally very easy. You can pull your complete wiki history as mercurial
  60. repository and do whatever you want with it.
  61. The bug tracker in bitbucket is probably the weakest part of the system.
  62. While it provides a simple ticket system it is missing a good mercurial
  63. integration (eg: that it listens for "this commit fixes #42") and
  64. automatically closes / reopens tickets based on that information. There
  65. is also no way to import or export the tickets as far as I can see but I
  66. guess that this is a feature that could come in the future.
  67. What's missing compared to Google code is a file hosting facilty. I
  68. don't think that this is something bitbucket should provide in the
  69. future, but that's definitively something a separate project shold try
  70. to fix. Now that sourceforge is starting to look more and more like a
  71. domain parking site and being less useful than ever, it's time for
  72. someone to stand up and provide file and website serving :)
  73. There are some things I'm missing on bitbucket currently that would be
  74. nice to have. For example it would help mirroring a lot if it was
  75. possible to add ssh keys directly to a project instead to a user so that
  76. I can grant write access to an ssh key that is only used for mirroring.
  77. Integration with CIA (the announcer bot) would be kick-ass too. Maybe it
  78. would even possible to specify incoming hooks in form of urls. Every
  79. time a changegroup comes in bitbucket would traverse the list of URLs
  80. and send them a summary of the changesets as JSON dump. As noticed above
  81. tracker <-> mercurial integration would be a nice to have as well as
  82. export / import support for it.
  83. I'm really impressed by bitbucket by now and can only recommend it for
  84. project hosting. Most important: you are not selling your soul to
  85. anyone. If you are unhappy with what you get, you can grab *all your
  86. data* and go somewhere else thanks to mercurial. And that this is
  87. possible should also give you a good feeling because it means that the
  88. people behind bitbucket will care about you to not loose you. Because
  89. the success of a website always depends on the number of happy users :-)
  90. The (by now inofficial) pocoo mirrors are `listed on my bitbucket
  91. account <http://www.bitbucket.org/mitsuhiko/>`_. Don't get the headline?
  92. `Read up bit bucket <http://en.wikipedia.org/wiki/Bit_bucket>`_.