Bazaar/LaunchPad, Mercurial/BitBucket, and Subversion/GoogleCode
Ian Charnas
Tortuga headquarters.
I spent all day today doing test-runs of mercurial and bazaar... and
bitbucket and launchpad. Here's my personal opinions on where I want
to go from here. I really want to move to a DVCS system. I want to
be able to save my changes all the time without having to commit
broken code to a central repository. I want to be able to work on a
team without a central repository, and work offline. I also want it
to be easier than using svn, when viewed from the standpoint of
someone who has never used a version control system.
Taking another look at BitBucket I see that it has indeed changed a
lot since the last time I looked. The interface is clean, the Open ID
is useful, and the compressed downloads are like automatic releases -
very nice. I would now definitely consider using BitBucket for some
of my projects. BitBucket's free account only goes up to 150 Mb
however, and it only works with Mercurial, which I have grown to
dislike, personally. Mercurial certainly works as advertised, in
terms of providing distributed VCS functionality... but I quickly got
annoyed trying to read Mercurial's changeset numbers (example:
r9538:f995b066ed61), and I got annoyed at the slow clone time for
large projects. Because Mercurial downloads the entire revision
history when you clone a repository, the clone times will get slower
and slower the more you develop. I know there's ways to get around
this, but they are experimental at this point. Also there's no true
support for file renaming, continuous svn integration is difficult,
and so on.
Bazaar on the other hand, lets you do a quick download of just the tip
(most recent version), using "bzr branch --stacked". Also, in
addition to being able to do a branch (aka clone), you can do a
"checkout", which automates the "bzr push" when you do a commit. You
can even use "bzr checkout --lightweight" to get just the tip (and
avoid downloading the entire revision history). The revision numbers
are readible (example: 17.1.1), and it has true support for file and
directory renaming. The newest version of Bazaar (1.9) has built-in
integration with svn repositories (the bzr-svn stuff is already in
there), and the binary installation worked fine [1] on my OS X 10.5
installation. However, LaunchPad (designed for Bazaar) on the other
hand is my least favorite hosting option. The interface is messy,
it's hard to find the buttons I'm looking for, there's no wiki, and
the server response always seems slow. I know it supports related
projects, and there's a lot of people using it, but I don't think that
LaunchPad is the best option for Tortuga.
I also looked at using Bazaar and Trac, which would be great because
Trac is easy and familiar and open-source. However, Trac kept leaking
memory.. and the plugins (including auth plugins) keep breaking
between versions, it's just a pain to administer.
I like Google Code because so many of us already have google accounts,
the interface is incredibly simple, and it's got a wiki and downloads
and customizable tabs, it's fast, and we can request more space if we
ever hit the quotas (100mb subversion, 250mb file downloads). Plus
I've already written a "python setup.py google_upload" setuptools
command that automates releases through google code.
So, what I'd like to do is to continue to use Google Code for hosting,
and use Bazaar for development. We'll still use the subversion
repository on google code (which integrates with the issue tracker),
but I'll change the "source" tab so that it documents how to use
Bazaar (with the integrated bzr-svn stuff) to develop on this project.
This way, people can have a choice between svn and bzr.
Before I make these changes, I want to hear from interested people.
What's your opinion? Please do educate me if you think I'm missing
something, or if any of my facts are incorrect.
-Ian
[1] Ok actually I got bit by this bug when I used "bzr commit" on a
bzr-svn checkout:
https://bugs.launchpad.net/bzr/+bug/293440
but the one-line patch listed in that bug report fixed things right
up, and if you use 0.10rc1 the fix is already in there.
Lee Olayvar
Have you given any thought as to how we will track plugins? I personally feel strongly that it is important for the community to have a central place to find plugins. Not only to find them, but to know that they are up to date aswell. Drupal does this by actually hosting plugins, and somehow linking repositories to the projects (i believe the repos are actually in drupal aswell). Another advantage of having a standardized place for plugins, is the ability for a tortuga install to actually check the installed plugins for updates, to see if there are security patches, etc.
With that said, Tortuga is very early and i dont think we fully need to address this issue until it has progressed further. Perhaps when Tortuga is bigger, we could do something very similar to Drupals method, or perhaps by that time Google Code will have advanced to offer an API to integrate Tortuga and Google Code to the point where Tortuga knows when a plugin _needs_ to be upgraded for a security reason. Or perhaps by that time Launchpad will have cleaned up their interface more.
Thanks for giving us a post, i look forward to digging into some tortuga plugins :)
--
Lee Olayvar
Ian Charnas
> As long as bzr-svn has no big issues, this would work fine for me. I
> personally haven't used bzr-svn a ton, but the bit i did i found a few
> problems.. hopefully they'll be ironed out soon enough though.
compiling special stuff for those on a mac (it comes pre-packaged), no
more problems with https, and so on.
> Have you given any thought as to how we will track plugins? I personally
> feel strongly that it is important for the community to have a central place
> to find plugins. Not only to find them, but to know that they are up to date
> aswell. Drupal does this by actually hosting plugins, and somehow linking
> repositories to the projects (i believe the repos are actually in drupal
> aswell). Another advantage of having a standardized place for plugins, is
> the ability for a tortuga install to actually check the installed plugins
> for updates, to see if there are security patches, etc.
was pretty well developed, and used setuptools to handle dependencies
and versions and making all the plugins importable via "import
pagoda.plugins". Installing was all done through easy_install. It
didn't matter where the plugins were hosted. This way plugin
developers can use whatever development tools and repo layouts and
server technologies they like for their plugins.
Mark Ramm
Jorge Vargas
> But I think it is good to do something like the plone collective, or the
> drupal plugins site so that plugins are easy to find, easy to manage.
> One of the nice things about the collective is that it's all ultimately one
> repository, so if a developer of a particular plugin disappears for some
> reason it will be easy for someone new to take it over.
> --Mark Ramm
Totally agred on this, as for using svn +bazaar I guess every project
has it's own thing so I can live with it.
Ian Charnas
With Google Code, we can't do any access control, so there's no way to
prevent a plugin developer from messing up another plugin on accident.
Also I don't know if google code's SVN does revisioned property
changes, so we might not be able to use svn:externals because doing a
checkout on an old revision of tortuga would always get the newest
versions of the plugins, which could be incompatible. So I don't
think we could use google code for a centralized plugin repository.
We could use a non-google-code solution to provide a centralized
plugin repository... but then there'd be two different systems for
people to learn, and it would be confusing to have two bucktracker
systems, two different kinds of authentication, and so on. It's an
option, but maybe we can find a better one.
How about this - for the time being, we'll use google code and bazaar
through bzr-svn. Once we get a stable "1.0" type release out, and the
API is stable enough that people can contribute some serious plugins,
at that point we'll look at our options again and figure out how we
can have a centralised plugin repository. Maybe by then the solution
will be Bazaar with Trac and OpenID... or maybe BitBucket will start
talking with Bazaar... or maybe Canonical will make a "LaunchPad
Lite" that's streamlined and easy to use.
In any case I will remain open to moving Tortuga to another hosting
service in the future.
ian
Mark Ramm
The potential for programmers to screw up a completely different pluging is there, but it is highly unlikely to happen, and it's easy enough to find out who did something bad and publicly shame them before reverting their change, so I don't think it's likely to be much of a problem in the real world.
But, one of the reasons I suggested hg+trac is that we've got a way to make it easy to setup a new trac instance and new hg repository easily through the web so it should be easy to make that work for a plugin repository.
That said, I think too much time has been spent on this already and none of it makes any difference if we don't yet have a functioning tortuga, so I'm all for going with Google Code and working whatever we need to work out later.
--Mark
Ian Charnas
> I would mention that the plone collective uses no access control, and no svn
> externals and they have not had any trouble making it work, so even if we
> use google code for a "collective" plugin repo we will likely be fine.
Oh wow, I didn't know that! I like what they've done with granting
'commit' access:
http://plone.org/development/info/write-access-collective
> The potential for programmers to screw up a completely different pluging is
> there, but it is highly unlikely to happen, and it's easy enough to find out
> who did something bad and publicly shame them before reverting their change,
> so I don't think it's likely to be much of a problem in the real world.
I really like that. I would be fine with a wide-open collective
repository just like you described. I'm sure we'll work something
out.
> But, one of the reasons I suggested hg+trac is that we've got a way to make
> it easy to setup a new trac instance and new hg repository easily through
> the web so it should be easy to make that work for a plugin repository.
I took a good look at that. I really like Trac... but I really
*really* don't want to use Mercurial. If they fixed those things I
mentioned though, I would take another look at it and keep an open
mind. I would be pretty happy with a Bazaar+Trac solution, once it's
a little more stable (maybe just a few months!). I bet when the time
is right, I could hack a branch of that hg+trac solution to use bzr
instead of hg... if the code can be made available, that is. Let's
get the CMS pieced together before we worry about it though.
> That said, I think too much time has been spent on this already and none of
> it makes any difference if we don't yet have a functioning tortuga, so I'm
> all for going with Google Code and working whatever we need to work out
> later.
Thanks Mark. I'm very open to change, let's get a functional CMS and
then evaluate hosting options again.
ian
Lee Olayvar
How about this - for the time being, we'll use google code and bazaar
through bzr-svn. Once we get a stable "1.0" type release out, and the
API is stable enough that people can contribute some serious plugins,
at that point we'll look at our options again and figure out how we
can have a centralised plugin repository. Maybe by then the solution
will be Bazaar with Trac and OpenID... or maybe BitBucket will start
talking with Bazaar... or maybe Canonical will make a "LaunchPad
Lite" that's streamlined and easy to use.
In any case I will remain open to moving Tortuga to another hosting
service in the future.
--
Lee Olayvar
Jorge Vargas
>
> Ok everybody thanks for your patience. I'm back in action here at
> Tortuga headquarters.
into this, all the what to do when the project grows will be deal
with, when the project grows, and for now all we need is a link for
tickets and another for code so use whatever pleases you.
But I'll like to answer so of your concerns, more as a "thank you for
tortuga" rather than a "lets use mercurial"
> BitBucket's free account only goes up to 150 Mb
> however, and it only works with Mercurial, which I have grown to
> dislike, personally.
they will sponsore bigger repos for open source stuff, although I
don't disagree that paying them is bad, they have to pay for their
servers!
> Mercurial certainly works as advertised, in
> terms of providing distributed VCS functionality... but I quickly got
> annoyed trying to read Mercurial's changeset numbers (example:
> r9538:f995b066ed61),
use the changeset number and we use the rev from trac as the canonical
way, I know it kind of defeats the purpose but if you make sure not to
make local branches you could rely 100% on rev numbers.
> and I got annoyed at the slow clone time for
> large projects. Because Mercurial downloads the entire revision
> history when you clone a repository, the clone times will get slower
> and slower the more you develop. I know there's ways to get around
> this, but they are experimental at this point.
clone the thing fully, that is what a clone means, if you want only
the last version then use the tar/zip/etc downloads.
> Also there's no true
> support for file renaming, continuous svn integration is difficult,
> and so on.
>
http://pypi.python.org/pypi/hgsvn/ works really well, now one thing to
note is that all these svn to X tools aren't really needed if the
central repo is in X, they are mostly there and develop for people
that don't have commit rights or/and are not the maintainer of the
main repo which could be converted over.
> Bazaar on the other hand, lets you do a quick download of just the tip
> (most recent version), using "bzr branch --stacked". Also, in
> addition to being able to do a branch (aka clone), you can do a
> "checkout", which automates the "bzr push" when you do a commit.
our are you talking pushing back to the svn server?
> You
> can even use "bzr checkout --lightweight" to get just the tip (and
> avoid downloading the entire revision history). The revision numbers
> are readible (example: 17.1.1), and it has true support for file and
> directory renaming. The newest version of Bazaar (1.9) has built-in
> integration with svn repositories (the bzr-svn stuff is already in
> there), and the binary installation worked fine [1] on my OS X 10.5
> installation. However, LaunchPad (designed for Bazaar) on the other
> hand is my least favorite hosting option. The interface is messy,
> it's hard to find the buttons I'm looking for, there's no wiki, and
> the server response always seems slow. I know it supports related
> projects, and there's a lot of people using it, but I don't think that
> LaunchPad is the best option for Tortuga.
>
> I also looked at using Bazaar and Trac, which would be great because
> Trac is easy and familiar and open-source. However, Trac kept leaking
> memory.. and the plugins (including auth plugins) keep breaking
> between versions, it's just a pain to administer.
>
> I like Google Code because so many of us already have google accounts,
> the interface is incredibly simple, and it's got a wiki and downloads
> and customizable tabs, it's fast, and we can request more space if we
> ever hit the quotas (100mb subversion, 250mb file downloads). Plus
> I've already written a "python setup.py google_upload" setuptools
> command that automates releases through google code.
>
sadly they only support svn.
Ian Charnas
thinking about it. When we get a functional tortuga running, let's
open up this discussion again. -Ian
Lee Olayvar
http://code.google.com/p/support/issues/list
The 2nd issue (the only _real_ issue, seeing as the 1st issue is discouraging stupid +1 comments) is the DVCS issue. It was originally said that Google Code will not use a DVCS and is sticking with SVN, but eventually they changed the status to Started and commented that it is now In Progress! High Priority to boot.
Not sure what system they'll go with, im hoping for Git, but who knows. Anything will be better than SVN :). Someone did mention though, that the Andriod source is using Git, so i'd say its pretty safe to assume they'll use Git. Which i have used in the past, and like a lot.
Lee Olayvar
Jorge Vargas
09 back in October :(
But ones they do I'll probably use them more.
Lee Olayvar
On a side note, have we given any thought to simply hosting the code elsewhere? Is it really that important that the project page and the code are in the same place? I like integration as much as the next guy, it does make it look all spiffy and whatnot, but i believe the main choices here have revolved around the standard user. In my opinion, any standard user who would have trouble navigating around a website to submit a bug report, probably would not even understand what the code is if he/she were to look at it.
If we separated the two, the code could go anywhere, and changing in the future would be much less of a hassle (given that nerds can adapt quickly ;)).
Anyone have any thoughts on this? Because if we took this route, we could use anything heh. Git/Github, Mercurial/BitBucket, Bazaar/Launchpad, etc, anything would be open to us.
Again, this discussion is not ment to be for the current Tortuga. Im dying to get into tortuga plugin writing (i want to get my install up and running after all), but i dont think theres anything wrong in discussing this. (Heck i dont think it has even slowed tortuga development down.. but thats just me)
Lee Olayvar
Jorge Vargas
barrier of entry to be successful at it's entry stages. On the other
hand integration is there because it's good, for example in trac if do
you a commit saying "fixes #34" it will add a link to ticket #34on the
changelog. That kind of thing is great long term.
Lee
On Dec 7, 11:04 am, "Jorge Vargas" <jorge.var...@gmail.com> wrote:
> I don't like that idea, any open source project must present the least
> barrier of entry to be successful at it's entry stages. On the other
> hand integration is there because it's good, for example in trac if do
> you a commit saying "fixes #34" it will add a link to ticket #34on the
> changelog. That kind of thing is great long term.
I'm just saying if we end up using something where integration
provides no real benefit, and does nothing but annoy developers (svn),
then i feel its debatable.
But if Google Code does indeed integrate committing with the issue
tracker, then that would be a bonus to have them bundled together.