Bitbucket now rocks Git(blog.bitbucket.org)
blog.bitbucket.org
Bitbucket now rocks Git
http://blog.bitbucket.org/2011/10/03/bitbucket-now-rocks-git/
33 comments
For me and where I work, GitHub's repo restrictions are the one and only cause of us self-hosting a Git server instead of using them. We have around a hundred small, low-traffic repos.
Let's put it this way:
* on GitHub, thanks to our repo count, we would be a $200/mo Platinum account
* on Bitbucket, thanks to our user count, we would be a $0/mo Free account, although we might have to upgrade all the way up to a $10/mo account as we're adding some people.
Needless to say, I will be looking hard at Bitbucket now that they're supporting Git.
Let's put it this way:
* on GitHub, thanks to our repo count, we would be a $200/mo Platinum account
* on Bitbucket, thanks to our user count, we would be a $0/mo Free account, although we might have to upgrade all the way up to a $10/mo account as we're adding some people.
Needless to say, I will be looking hard at Bitbucket now that they're supporting Git.
> GitHub's repo restrictions
You're talking about the number limit?
You're talking about the number limit?
thanks to our repo count
I guess this answers your question. I'm a happy Github customer myself (both personally as well as with my company), but it is interesting to see Bitbucket compete with them head-on. I can see quite a lot of small/medium companies move over.
I guess this answers your question. I'm a happy Github customer myself (both personally as well as with my company), but it is interesting to see Bitbucket compete with them head-on. I can see quite a lot of small/medium companies move over.
This x100. I love GitHub's user interface but as a poor student couldn't justify them for my private projects (until I found their free student plan), so I used BitBucket.
BitBucket is very good from a pricing and support point of view (and I actually preferred Mercurial before I learnt Git properly) but it's not nearly as polished as GitHub - one thing that springs to mind (it might have been fixed) was it trying to show me a complete diff of Xcode project files when I clicked on a commit causing my browser to crash. Pretty much the main reason I switched.
I'd be really keen to see some real competition in the hosted social-coding space (it's funny, that sentence wouldn't have made sense just a few years ago), and Atlassian has the resources to do it.
BitBucket is very good from a pricing and support point of view (and I actually preferred Mercurial before I learnt Git properly) but it's not nearly as polished as GitHub - one thing that springs to mind (it might have been fixed) was it trying to show me a complete diff of Xcode project files when I clicked on a commit causing my browser to crash. Pretty much the main reason I switched.
I'd be really keen to see some real competition in the hosted social-coding space (it's funny, that sentence wouldn't have made sense just a few years ago), and Atlassian has the resources to do it.
Where can I find out about the student plan?
I only found it by Googling in desperation; they don't exactly advertise it (which I guess is fair enough).
I have a similar sentiment. It doesn't feel right to pay for a private repo that you don't use any of the collaborative features.
I wonder if it makes sense for github to have a 'lite' repo that is just straight up storage, no extra features. This would be valuable to me because even though I can set up a bitbucket account and get the free private repos, I just like having everything in one place. I feel like they could even tack on a small amount to the normal subscription fee, or be able to add these on a la carte for an added monthly cost.
Don't get me wrong, I love the collaborative features and UI when I am working on the project with others, but for solo projects and old projects I don't update often this would be great.
I wonder if it makes sense for github to have a 'lite' repo that is just straight up storage, no extra features. This would be valuable to me because even though I can set up a bitbucket account and get the free private repos, I just like having everything in one place. I feel like they could even tack on a small amount to the normal subscription fee, or be able to add these on a la carte for an added monthly cost.
Don't get me wrong, I love the collaborative features and UI when I am working on the project with others, but for solo projects and old projects I don't update often this would be great.
Why not just use Dropbox + Git? That's what I do.
Please be aware of the dangers when you do this: http://news.ycombinator.com/item?id=3024460
Or heroku. No one says you have to use the app you deploy. just put a dummy rackup file in your homedir.
we'll see how GH responds in the face of competition like this. Now I no longer need to go beyond the $7/month github plan.
I could see GH creating an "unlimited" account for $20/month that allows up to 3mb of files and unlimited repos.
I could see GH creating an "unlimited" account for $20/month that allows up to 3mb of files and unlimited repos.
I think an appropriate GH response would be to make a few/all personal (aka 0 collaborators) private repos free.
This is a _stellar_ idea.
I just wonder if there's a bit of a culture-jam here. It'd tempt you to not open up projects as freely, which seems at odds with the ideals of the GH camp.
I just wonder if there's a bit of a culture-jam here. It'd tempt you to not open up projects as freely, which seems at odds with the ideals of the GH camp.
The public repo thing is a bit odd anyway. Many public projects don't have a license attached to them. So they're not really open source, they're not public domain, they're just publicly viewable but you have no license to use it.
[deleted]
They'd be nuts to do that. They are getting $7/month from me, for a few private repos, and I bet I'm not the only one. If they up the number of private repos, I'll stick with them, rather than porting my inactive ones to bitbucket. But I doubt they'll make them completely free, even though the competition is free.
They have a great business model - free repos for OSS drives users, then they get users to pay a smallish (in absolute terms) cost for private repos. All they need is the million odd developers who use their system for OSS, and they will shake a few bucks out of each somehow. There's no need for them and BB to compete as though they were selling commodity products. Both are competing on getting people used to their interface (by OSS products) and then charging then whatever they think won't cause too much pain.
That said, people with lots of small repos are feeling unnecessary pain from Github's pricing scheme.
They have a great business model - free repos for OSS drives users, then they get users to pay a smallish (in absolute terms) cost for private repos. All they need is the million odd developers who use their system for OSS, and they will shake a few bucks out of each somehow. There's no need for them and BB to compete as though they were selling commodity products. Both are competing on getting people used to their interface (by OSS products) and then charging then whatever they think won't cause too much pain.
That said, people with lots of small repos are feeling unnecessary pain from Github's pricing scheme.
The difference is that BitBucket pricing is based on the number of collaborators. Their pricing page makes it seem like you even have to pay to have more than 5 collaborators on a public repo, whereas with github you don't. If I'm reading it right, then Github is still really good for Open Source projects that intend to have more than a handful of collaborators. While BitBucket is a good place to stick your private repos where you have few (or no) contributors.
From https://bitbucket.org/plans :
What is a user?
Someone with read or write access to one of your private repositories.
What is a user?
Someone with read or write access to one of your private repositories.
Nevermind then. Apparently I'm blind.
My company has many very small projects that needed to be archived yet weren't completely closed (possible to re-open for new feature). We started with GitHub but were forced to leave since they didn't have any viable plans - ended up moving to SpringLoops which charges on "active" projects. Basically we can close and re-open as many projects as we'd like as long as < 10 are active.
I agree -- I have too many repos I'd like to keep private to host them on github, but would love to if I could.
I'm currently paying for a prgmr instance just to run gitolite (https://github.com/sitaramc/gitolite) so I could have a private place to store remotes for my repos. I'm planning to move to bitbucket immediately.
I'm currently paying for a prgmr instance just to run gitolite (https://github.com/sitaramc/gitolite) so I could have a private place to store remotes for my repos. I'm planning to move to bitbucket immediately.
You know, I actually expected that the opposite would happen: GitHub would start offering Mercurial hosting.
Because Git isn't what attracts most people to GitHub. It's the sheer fact that GitHub is frickin' HUGE and has lots of people who will show up, fork your project, and send you a pull request. I love Bitbucket, but honestly if GitHub added Mercurial support I would probably move all the way to GitHub because of the size of the community.
GitHub is already pretty firmly entrenched in the Git community. I will say, however, that Bitbucket has one primary advantage over GitHub: Unlimited private repositories, with the cost being based on how many collaborators you have. If Bitbucket really promotes this angle, I could see a lot of small development teams moving to Bitbucket, and possibly taking their talent with them. So, if Bitbucket really pushes the "unlimited private repositories" angle, then they could begin taking back market share from GitHub.
Because Git isn't what attracts most people to GitHub. It's the sheer fact that GitHub is frickin' HUGE and has lots of people who will show up, fork your project, and send you a pull request. I love Bitbucket, but honestly if GitHub added Mercurial support I would probably move all the way to GitHub because of the size of the community.
GitHub is already pretty firmly entrenched in the Git community. I will say, however, that Bitbucket has one primary advantage over GitHub: Unlimited private repositories, with the cost being based on how many collaborators you have. If Bitbucket really promotes this angle, I could see a lot of small development teams moving to Bitbucket, and possibly taking their talent with them. So, if Bitbucket really pushes the "unlimited private repositories" angle, then they could begin taking back market share from GitHub.
Git isn't what attracts most people to GitHub
GitHub is indeed a sort of social-network for developers working on open-source projects, and this makes it really attractive. Their interface is also totally kick-ass and I love them.
But for my private projects GitHub is totally useless and also expensive, which is why I have been hosting my own Git repo on an instance that I own - it's pretty easy to setup too.
I am very excited that Bitbucket is offering Git as an option, as Mercurial for me is not really compelling; not that Git is necessarily better but it's what I know and have absolutely no reason to learn yet-another-tool-that-does-the-same-thing.
Opposite for me. I never really knew whether to choose Mercurial, Bzr or Git and ended up using Git for everything because of Github.
> But for my private projects GitHub is totally useless and also expensive, which is why I have been hosting my own Git repo on an instance that I own - it's pretty easy to setup too.
Ditto. There's a number of projects that I just won't put online because I'd rather lose than share them. With Bitbucket it looks like I'll be able to stash them privately, for free.
I'm totally psyched that Bitbucket has given this good a plan as their base/free package.
Ditto. There's a number of projects that I just won't put online because I'd rather lose than share them. With Bitbucket it looks like I'll be able to stash them privately, for free.
I'm totally psyched that Bitbucket has given this good a plan as their base/free package.
> There's a number of projects that I just won't put online because I'd rather lose than share them.
Assuming that those projects don't generate much revenue for you [1], what's the point of keeping them private?
From a political point of view, I always see such projects as a good opportunity to promote Free Software. From an economic point of view, I like to put some pressure on my competitors that way. For really valuable stuff, I'm using strict licenses like GPLv3 or AGPLv3 which ensure that sharing won't result in any disadvantage for me.
So I really wonder (as a seriously meant question!) what kind of projects you are talking about. What kind of non/small-revenue project would anyone rather lose than share?
[1] Otherwise I'd wonder why you couldn't afford paying GitHub, and also couldn't afford to switch to Mercurial for hosting them on BitBucket for free.
Assuming that those projects don't generate much revenue for you [1], what's the point of keeping them private?
From a political point of view, I always see such projects as a good opportunity to promote Free Software. From an economic point of view, I like to put some pressure on my competitors that way. For really valuable stuff, I'm using strict licenses like GPLv3 or AGPLv3 which ensure that sharing won't result in any disadvantage for me.
So I really wonder (as a seriously meant question!) what kind of projects you are talking about. What kind of non/small-revenue project would anyone rather lose than share?
[1] Otherwise I'd wonder why you couldn't afford paying GitHub, and also couldn't afford to switch to Mercurial for hosting them on BitBucket for free.
I work on self-developed projects as a consultant that I don't have the rights to open source. Because of that, I need to use Github's paid account plan, even though I'm the only person who contributes code to that project. So, I'll be seriously considering bitbucket as an alternative host, because it could save me ~£85/year.
Not poster but in a similar position myself.
What about incomplete projects? Messy/hacky experiments? Completely idiotic/backwards stuff done for fun? Play-projects purely attempted for "ha I did it!"? Legally-grey (or blatantly illegal) projects? Or even school projects? I have hundreds of projects that fit in those categories, and none will ever be made publicly available. Sometimes it's just not good form to make a project public, other times it's clearly harmful to do so.
Nevertheless, I preserve my projects privately just in case I ever resume work on a whim, or want to reference what I did in the past (or more likely, what I did wrong). And now I can put them online privately for free, sharing with those I deem appropriate.
What about incomplete projects? Messy/hacky experiments? Completely idiotic/backwards stuff done for fun? Play-projects purely attempted for "ha I did it!"? Legally-grey (or blatantly illegal) projects? Or even school projects? I have hundreds of projects that fit in those categories, and none will ever be made publicly available. Sometimes it's just not good form to make a project public, other times it's clearly harmful to do so.
Nevertheless, I preserve my projects privately just in case I ever resume work on a whim, or want to reference what I did in the past (or more likely, what I did wrong). And now I can put them online privately for free, sharing with those I deem appropriate.
> incomplete projects?
It depends on what you mean by "incomplete". 50 lines of code which do almost nothing useful are probably not worth publishing. But why not publishing a half-complete project? Publishing may help you find contributors. And the early feedback helps you to decide if your project is worth more intense attention.
> Messy/hacky experiments?
If the code is not too bad, I publish even that stuff (as long as it is big enough to be notable), e.g.
http://pypi.python.org/pypi/vserver
> Completely idiotic/backwards stuff done for fun?
I recently published such a project and got surprisingly great feedback:
http://news.ycombinator.com/item?id=3061050
> Play-projects purely attempted for "ha I did it!"?
Why not? You never know who'll like it anyway, e.g.
http://sourceforge.net/projects/hosh/
> Legally-grey (or blatantly illegal) projects?
Depending on how much trouble this might cause, you probably shouldn't upload it anywhere. Even a "private" repository on GitHub/BitBucket might be too risky.
On the other hand, I know about a Free Software clone of a game that used the original graphics and music. Not quite legal, but the game was very old and the right holders obviously didn't care. However, after publishing the project got a little fan base that eventually included graphic designers and musicians, who replaced the proprietary stuff step by step with their own creations. So the game changed from "legally-grey" to "solid free". This would never have been possible if the game hadn't been published.
> Or even school projects?
My school projects were about the first ones I published, and I'm pretty proud about what I wrote in that age, e.g.
http://davis.sf.net/
http://sourceforge.net/projects/voji/
http://sourceforge.net/projects/volt/
Later I also published some notable university project works (sorry, German language):
http://www.profv.de/uni/
However, these are only project works. I will never publish specific solutions to homework excercises, as this would only help cheaters and nobody else.
It depends on what you mean by "incomplete". 50 lines of code which do almost nothing useful are probably not worth publishing. But why not publishing a half-complete project? Publishing may help you find contributors. And the early feedback helps you to decide if your project is worth more intense attention.
> Messy/hacky experiments?
If the code is not too bad, I publish even that stuff (as long as it is big enough to be notable), e.g.
http://pypi.python.org/pypi/vserver
> Completely idiotic/backwards stuff done for fun?
I recently published such a project and got surprisingly great feedback:
http://news.ycombinator.com/item?id=3061050
> Play-projects purely attempted for "ha I did it!"?
Why not? You never know who'll like it anyway, e.g.
http://sourceforge.net/projects/hosh/
> Legally-grey (or blatantly illegal) projects?
Depending on how much trouble this might cause, you probably shouldn't upload it anywhere. Even a "private" repository on GitHub/BitBucket might be too risky.
On the other hand, I know about a Free Software clone of a game that used the original graphics and music. Not quite legal, but the game was very old and the right holders obviously didn't care. However, after publishing the project got a little fan base that eventually included graphic designers and musicians, who replaced the proprietary stuff step by step with their own creations. So the game changed from "legally-grey" to "solid free". This would never have been possible if the game hadn't been published.
> Or even school projects?
My school projects were about the first ones I published, and I'm pretty proud about what I wrote in that age, e.g.
http://davis.sf.net/
http://sourceforge.net/projects/voji/
http://sourceforge.net/projects/volt/
Later I also published some notable university project works (sorry, German language):
http://www.profv.de/uni/
However, these are only project works. I will never publish specific solutions to homework excercises, as this would only help cheaters and nobody else.
> However, these are only project works. I will never publish specific solutions to homework excercises, as this would only help cheaters and nobody else.
Which is why (lite) private repoes would be nice. I wouldn't want to hand out all the answers to my school assignments but I'd still like to keep them tracked with git (depending on the size). At the moment I've just put my coding folder inside Dropbox which in a way acts like version control (in the sense that I won't lose the code.
On the other hand, I know about a Free Software clone of a game that used the original graphics and music. Not quite legal, but the game was very old and the right holders obviously didn't care. However, after publishing the project got a little fan base that eventually included graphic designers and musicians, who replaced the proprietary stuff step by step with their own creations. So the game changed from "legally-grey" to "solid free". This would never have been possible if the game hadn't been published.
I voted you up specifically for this bit. This is great.
What game was cloned, and what is the name of the clone?
I voted you up specifically for this bit. This is great.
What game was cloned, and what is the name of the clone?
Sounds an awful lot like he's talking about OpenTTD, a "clone" of Transport Tycoon Deluxe that has some "interesting" history even aside from the media assets.
what's the Free Software clone of a game?
This term means that a proprietary game has been rewritten completely from scratch as a Free Software project.
Usually, the game principle stays the same, but has its own codebase, and different graphics and music. Sometimes names are changed, too, if the original names were trademarked. After some time, the Free Software clones usually surpass the original game in almost every aspect.
This is a great way for a fan community to push forward their favorite game long after the producers lost their (commercial) interest in it.
This is also some kind of sustainability, as it ensures the game won't die with the hardware it was produced for.
Usually, the game principle stays the same, but has its own codebase, and different graphics and music. Sometimes names are changed, too, if the original names were trademarked. After some time, the Free Software clones usually surpass the original game in almost every aspect.
This is a great way for a fan community to push forward their favorite game long after the producers lost their (commercial) interest in it.
This is also some kind of sustainability, as it ensures the game won't die with the hardware it was produced for.
> Depending on how much trouble this might cause, you probably shouldn't
> upload it anywhere. Even a "private" repository on GitHub/BitBucket might
> be too risky.
Some other examples:
1. You want to keep track of your dotfiles that you use at work. In general, this may be ok to put public, but it may contain work-specific stuff (hostnames, configurations, etc) that might get you in trouble for publishing publicly. For example, my work shell config has aliases that include connection information (sans password) to internal databases.
2. Resumes and/or cover letters. If you update your resume to say that you're looking for work, or looking for work in another area, this could give info to your current employer that you don't want to hand out. You might also want to keep your cover letters in version control if you use something like LaTeX or have specfic parts that you want to be boilerplate (e.g. description of yourself and/or your exerience). If you keep this in public, then everyone knows when/where you are applying for work, which may not be desirable even if your employer doesn't care.
I can afford to upgrade my Github account, but I'm a bit cheap when it comes to doing so.
I do a lot of experimentation and I'm of the opinion that not everything I do is worthy of sharing. I've partially written a web interface for pianobar, a feed to rss translator for reformatting NOAA forecasts (they discontinued the REST service), some wiki-like software, and even some barebones PBX interfaces for an Asterisk replacement.
The work that I have put on Github hasn't seen a ton of interest—not that they're terribly complete. But I did write a simple-but-useful-enough asynchronous "cron"[1] system for Go (BSD licensed). I got only 1 comment questioning how I implemented it with a qualified "good job" (if that).
I'm no Ryan Bates or Linus Torvalds. Several times I've interacted with OSS projects, run into trouble, and asked relevant questions. But because I'm not a linux/unix guru I get flamed (I just bought a Mac 16 months ago, gimme a break).
Why expose myself? I'm not trying to flame you, but I did want to express my long-standing disappointment with the "friendliness" of a number of communities (HN included).
[1]: https://github.com/rk/cron.go
I do a lot of experimentation and I'm of the opinion that not everything I do is worthy of sharing. I've partially written a web interface for pianobar, a feed to rss translator for reformatting NOAA forecasts (they discontinued the REST service), some wiki-like software, and even some barebones PBX interfaces for an Asterisk replacement.
The work that I have put on Github hasn't seen a ton of interest—not that they're terribly complete. But I did write a simple-but-useful-enough asynchronous "cron"[1] system for Go (BSD licensed). I got only 1 comment questioning how I implemented it with a qualified "good job" (if that).
I'm no Ryan Bates or Linus Torvalds. Several times I've interacted with OSS projects, run into trouble, and asked relevant questions. But because I'm not a linux/unix guru I get flamed (I just bought a Mac 16 months ago, gimme a break).
Why expose myself? I'm not trying to flame you, but I did want to express my long-standing disappointment with the "friendliness" of a number of communities (HN included).
[1]: https://github.com/rk/cron.go
> I'm of the opinion that not everything I do is worthy of sharing
The same is true for me. But who defines what is "worthy of sharing"? I believe this question is to be answered by others, not by oneself. It's generally hard to say whether something will be interesting or uninteresting to others, i.e. worthy or unworthy of sharing.
I've seen some surprises in the past after publishing pet projects which I thought weren't worth much, and weren't really complete. Nevertheless, some of them did get interest, and with the help of others they did become good and almost complete.
Of course there are also other projects which I published, which nobody else was interested in, where I finally lost interest and which are hopelessly outdated crap by now.
However, I couldn't have told you in advance which of my projects will or will not share this fate.
Having that said, I fully agree that one shouldn't publish every crap. But I have quite good experiences with: When in doubt, publish!
The same is true for me. But who defines what is "worthy of sharing"? I believe this question is to be answered by others, not by oneself. It's generally hard to say whether something will be interesting or uninteresting to others, i.e. worthy or unworthy of sharing.
I've seen some surprises in the past after publishing pet projects which I thought weren't worth much, and weren't really complete. Nevertheless, some of them did get interest, and with the help of others they did become good and almost complete.
Of course there are also other projects which I published, which nobody else was interested in, where I finally lost interest and which are hopelessly outdated crap by now.
However, I couldn't have told you in advance which of my projects will or will not share this fate.
Having that said, I fully agree that one shouldn't publish every crap. But I have quite good experiences with: When in doubt, publish!
Because Git isn't what attracts most people to GitHub. It's the sheer fact that GitHub is frickin' HUGE and has lots of people who will show up, fork your project, and send you a pull request. I love Bitbucket, but honestly if GitHub added Mercurial support I would probably move all the way to GitHub because of the size of the community.
This sums up my feelings exactly. I'm emphatically not a fan of the Github guys (who seem rather unprofessional), but the community is too big to ignore. I'll probably switch if/when they support hg, unless Atlassian can find a way to encourage a much more robust community in Bitbucket.
(And no, Github fans, hg-git is not "support" for hg.)
This sums up my feelings exactly. I'm emphatically not a fan of the Github guys (who seem rather unprofessional), but the community is too big to ignore. I'll probably switch if/when they support hg, unless Atlassian can find a way to encourage a much more robust community in Bitbucket.
(And no, Github fans, hg-git is not "support" for hg.)
"I'm emphatically not a fan of the Github guys (who seem rather unprofessional)"
How so? They're quite snappy with the support in my experience, and handled the firesheep situation much better than most companies.
How so? They're quite snappy with the support in my experience, and handled the firesheep situation much better than most companies.
Not the OP, but I sent a friendly note asking a question that was perhaps a bit dumb--just asking to clarify what one "collaborator" meant to them. The response I got back was a bit rude.
Keep in mind my email said I was choosing a subscription plan. As someone who has done support, being rude to people about to purchase your service is even dumber than the question I asked...
Keep in mind my email said I was choosing a subscription plan. As someone who has done support, being rude to people about to purchase your service is even dumber than the question I asked...
I encountered something similar as well with their subscription plans. This was before a friend pointed me to Bitbucket, at which I've been very happy since.
A lot of people/companies I know were using Assembla and Beanstalk.
I wonder how big a threat this is to them, rather than Github . I notice that Bitbucket hasnt integrated Issues tracker with git. Bitbucket's bug tracking was IMHO much superior to github.
Plus Bitbucket doesnt format the README markdown as nicely as Github.
EDIT: I notice that I was mistaken. you need to enable bug tracking from the admin tab.
I wonder how big a threat this is to them, rather than Github . I notice that Bitbucket hasnt integrated Issues tracker with git. Bitbucket's bug tracking was IMHO much superior to github.
Plus Bitbucket doesnt format the README markdown as nicely as Github.
EDIT: I notice that I was mistaken. you need to enable bug tracking from the admin tab.
Partially agree about the threat. This news generates a lot of marketing that could drive new users to Bitbucket instead of Assembla and Beanstalk. But for existing users (I've been using Assembla for a while for private repos) there is probably a lot less reason to switch over.
> I'm emphatically not a fan of the Github guys (who seem rather unprofessional)
How so?
How so?
They do support HG in a way. See http://hg-git.github.com/
I'll grant that only if you allow me to say that Linux runs Microsoft Office natively due to WINE.
no. That analogy doesn't fit here. A closer one would be more like Linux supporting FAT32 natively because someone took the time to write proper support for it in an system it wasn't originally designed for (and it works beautifully with almost no corner cases).
It may not perform as well but I get to use what I want and still interoperate.
It may not perform as well but I get to use what I want and still interoperate.
Fair enough; your analogy is better. But not for the reason you point out.
Because FAT32 naming conventions are radically different from Linux', and because it supports radically different directory restrictions, and because it has attributes that Linux doesn't understand, and because it doesn't support permissions, I have to always keep clearly in mind when I've mounted a FAT32 volume v. basically anything else. Yes, I can mount it, and it works just fine until it doesn't.
This is my experience with hg-git. Mercurial tags can be moved, Git tags can't be, so I need to keep that in mind. Mercurial signatures don't map to Git ones for obvious reasons or vice-versa, so I can't actually figure out whether a given release was signed by the project author. Mercurial branches lack Git analogs, so I have to remember not to use them. Mercurial bookmarks map to Git branches, so I have to be ready for bookmarks to move in odd ways as Git users work with my hg-git repository. Mercurial's multiple heads per branch have no real analog in Git (they'd be up for garbage collection). This list goes on.
When I use hg-git, I have to always keep the Git model in my head, AND keep the Mercurial model in my head, AND keep in mind how those two models interact. This isn't fun, and it's not anything remotely close to transparent. It's amazingly impressive how well hg-git works, but claiming that GitHub supports Mercurial due to hg-git is horribly misleading.
Because FAT32 naming conventions are radically different from Linux', and because it supports radically different directory restrictions, and because it has attributes that Linux doesn't understand, and because it doesn't support permissions, I have to always keep clearly in mind when I've mounted a FAT32 volume v. basically anything else. Yes, I can mount it, and it works just fine until it doesn't.
This is my experience with hg-git. Mercurial tags can be moved, Git tags can't be, so I need to keep that in mind. Mercurial signatures don't map to Git ones for obvious reasons or vice-versa, so I can't actually figure out whether a given release was signed by the project author. Mercurial branches lack Git analogs, so I have to remember not to use them. Mercurial bookmarks map to Git branches, so I have to be ready for bookmarks to move in odd ways as Git users work with my hg-git repository. Mercurial's multiple heads per branch have no real analog in Git (they'd be up for garbage collection). This list goes on.
When I use hg-git, I have to always keep the Git model in my head, AND keep the Mercurial model in my head, AND keep in mind how those two models interact. This isn't fun, and it's not anything remotely close to transparent. It's amazingly impressive how well hg-git works, but claiming that GitHub supports Mercurial due to hg-git is horribly misleading.
The hg-git abstraction is not very solid. You end up having to "think git" rather than "think hg" and my beef with git isn't in the syntax, it's in git.
If I'm going to use hg-git, I might as well use git itself. I don't want to use git; I want to use hg.
If I'm going to use hg-git, I might as well use git itself. I don't want to use git; I want to use hg.
Why? As a Git fan, someone's perspective on why they prefer Mercurial would be really interesting. What rocks about Mercurial?
Your question is difficult to answer in the light in which you intended it, because it doesn't really apply to me. I am not so invested in my source control system to say it "rocks". It works for my purposes and maps nicely to my view of how to handle source code--it's less that Mercurial is awesome, it's that I find Git unpleasant to work with.
I find Git over-engineered toward the wrong goals; while I don't doubt the development credentials of the Git developers, I think that too little time has been put into making developers' lives easier. Linus has said previously that speed was a priority for him, and that's great--for kernel sources, I'd definitely put a premium on speed. It appears, however, to come at a cost: Git has long struck me as extremely user-hostile. The documentation may have improved as of late (I haven't checked) but it was absolutely atrocious for a very long time. I find its interface unintuitive and nondiscoverable (and here hg-git could help, were it not for the cognitive dissonance of dealing with one against the other). And its Windows support, even today, is unacceptably poor given that I spend about 40% of my time working there.
hg-git addresses some of the more cosmetic issues noted above that I could, if so inclined, deal with myself, but it doesn't really address deeper concerns I have with Git itself. There are also issues of philosophy involved--Git requires you to accept certain behaviors and the cultural encouragement of same, e.g. rewritable history, of which I'm very much not a fan. (You can rewrite a Mercurial history as well, but it requires going out of your way to do so and is not culturally accepted. "Rebase" exists, via extensions, but nobody uses it. And I much prefer it that way.)
To me, Mercurial feels much more like its developers spent a bit more time thinking--looking at how a wider set of developers work, and building something that's comfortable to more people in less time. Git feels like its developers asked no questions at all and started hammering out what made sense to them. Which is fine when it maps to the way you think and the way you work, but it doesn't map to either for me.
(I also tend to think that Git wouldn't be nearly as popular had it not been reflexively adopted by everyone and their brother because of Github--this isn't "waah, my tool of choice isn't popular!", but more of a simple observation. I think it succeeds more in spite of itself than anything.)
I find Git over-engineered toward the wrong goals; while I don't doubt the development credentials of the Git developers, I think that too little time has been put into making developers' lives easier. Linus has said previously that speed was a priority for him, and that's great--for kernel sources, I'd definitely put a premium on speed. It appears, however, to come at a cost: Git has long struck me as extremely user-hostile. The documentation may have improved as of late (I haven't checked) but it was absolutely atrocious for a very long time. I find its interface unintuitive and nondiscoverable (and here hg-git could help, were it not for the cognitive dissonance of dealing with one against the other). And its Windows support, even today, is unacceptably poor given that I spend about 40% of my time working there.
hg-git addresses some of the more cosmetic issues noted above that I could, if so inclined, deal with myself, but it doesn't really address deeper concerns I have with Git itself. There are also issues of philosophy involved--Git requires you to accept certain behaviors and the cultural encouragement of same, e.g. rewritable history, of which I'm very much not a fan. (You can rewrite a Mercurial history as well, but it requires going out of your way to do so and is not culturally accepted. "Rebase" exists, via extensions, but nobody uses it. And I much prefer it that way.)
To me, Mercurial feels much more like its developers spent a bit more time thinking--looking at how a wider set of developers work, and building something that's comfortable to more people in less time. Git feels like its developers asked no questions at all and started hammering out what made sense to them. Which is fine when it maps to the way you think and the way you work, but it doesn't map to either for me.
(I also tend to think that Git wouldn't be nearly as popular had it not been reflexively adopted by everyone and their brother because of Github--this isn't "waah, my tool of choice isn't popular!", but more of a simple observation. I think it succeeds more in spite of itself than anything.)
I don't think user-friendliness should be a primary goal for a version control system. The reason being that this is something we use day in and day out for years, so the importance of the learning curve is dwarfed by the power of the UI and the workflows it enables.
When I switched from svn to git (and don't take this to mean I'm comparing svn to hg, because obviously hg is in git's league, not svn's), the learning curve was steep, but after 3 months of daily use I understood git's internals and what the various commands actually do infinitely better than I did after 5 years of using svn.
In other words, I think git has an internal logic that allows it to fit into a small space in your brain once fully grokked.
As to the rebase vs merge debate, I've already written about this (http://darwinweb.net/articles/the-case-for-git-rebase), but fundamentally my argument boils down to this: Having a linear history allows me to resolve historical bugs better than a history full of merge commits. If I run a bisect on a linear history I will always narrow down a bug to a single commit instead of potentially a merge commit with hundreds of commits behind it. Now, merge commits give you more information about the history, but when topic branches proliferate that information becomes very hard to make sense of anyway. With rebased commits I can still see when they were committed, so it's not as if there is no evidence of the actual development. Being able to see the exact state a particular commit was developed in is useful, but in my experience does not offset the hassle of a very messy history in solving bugs in the current state of the code base.
When I switched from svn to git (and don't take this to mean I'm comparing svn to hg, because obviously hg is in git's league, not svn's), the learning curve was steep, but after 3 months of daily use I understood git's internals and what the various commands actually do infinitely better than I did after 5 years of using svn.
In other words, I think git has an internal logic that allows it to fit into a small space in your brain once fully grokked.
As to the rebase vs merge debate, I've already written about this (http://darwinweb.net/articles/the-case-for-git-rebase), but fundamentally my argument boils down to this: Having a linear history allows me to resolve historical bugs better than a history full of merge commits. If I run a bisect on a linear history I will always narrow down a bug to a single commit instead of potentially a merge commit with hundreds of commits behind it. Now, merge commits give you more information about the history, but when topic branches proliferate that information becomes very hard to make sense of anyway. With rebased commits I can still see when they were committed, so it's not as if there is no evidence of the actual development. Being able to see the exact state a particular commit was developed in is useful, but in my experience does not offset the hassle of a very messy history in solving bugs in the current state of the code base.
I do think that user-friendliness must be a primary goal for a VCS, because I have to get people who aren't hardcore, balls-to-the-wall programmers to use it if I need to store their data in my tree. Hg can be picked up by those folks in short order and requires no "grokking" beyond what you can read on Spolsky's HG Init in half an hour minutes. (I have in the past worked with designers who were wholly out of their element with anything beyond HTML, CSS, and very simple jQuery-backed JavaScript; expecting them to "grok" their VCS was more of a demand than I wanted to make because I'd have had to teach them.) And, to be honest, I think having to "grok" your VCS is only slightly less ridiculous of a requirement for software to force upon its user than is having to "grok" your text editor. Similarly, is why I don't use vim and do use Sublime Text.
I don't think git's internal logic is more meaningfully flexible than hg's, but, IMO, hg provides a vastly more user-friendly experience. I could be wrong on this, but assuming I'm not--if you can get both, why not get both? =)
(And don't get me wrong--I realize the arguments for rebase as opposed to merge. I reject them for my own projects for reasons that are largely subjective, and prefer a system where they are difficult and not commonplace. It's totally a matter of taste, but one I do feel somewhat strongly about and is what I'm referring to by disagreements in philosophy.)
I don't think git's internal logic is more meaningfully flexible than hg's, but, IMO, hg provides a vastly more user-friendly experience. I could be wrong on this, but assuming I'm not--if you can get both, why not get both? =)
(And don't get me wrong--I realize the arguments for rebase as opposed to merge. I reject them for my own projects for reasons that are largely subjective, and prefer a system where they are difficult and not commonplace. It's totally a matter of taste, but one I do feel somewhat strongly about and is what I'm referring to by disagreements in philosophy.)
On text editors -- picking up Emacs was one of the hardest thing I ever did, as I had to learn new shortcuts, I had to learn to rely on the keyboard-only and I also had to learn some ELisp just to be able to configure it.
Because Emacs has some problems (it is hard to create new syntax-highlighting definitions, plugins break all the time, ELPA for package management is useless), I did try both Textmate and Sublime Text 2, several times.
But I keep going back to Emacs and personally I don't get how people can stand a text editor that doesn't even have proper UNDO (Textmate) or a text editor that doesn't have a workflow that is totally mouse-free. Emacs is also wonderful because it grows with you. Some things that should be simple are too hard indeed, but at least you can fix that.
Basically me switching to Emacs was similar to when I learned to touch-type. I did suffer, but productivity was increased tenfold in the end.
IMHO, you're not a user to require UI friendliness. The difference between a developer and a user is that users are using these applications casually. But if your day job is depending on a text editor, you should use the text editor that stays the least in your way, and friendliness has nothing to do with it. Ditto for version control.
On a side-note, race-car drivers in general do not use automatic transmissions. That's because they can change gears more efficiently than a computer can and because they don't need to eat sandwiches while driving.
Because Emacs has some problems (it is hard to create new syntax-highlighting definitions, plugins break all the time, ELPA for package management is useless), I did try both Textmate and Sublime Text 2, several times.
But I keep going back to Emacs and personally I don't get how people can stand a text editor that doesn't even have proper UNDO (Textmate) or a text editor that doesn't have a workflow that is totally mouse-free. Emacs is also wonderful because it grows with you. Some things that should be simple are too hard indeed, but at least you can fix that.
Basically me switching to Emacs was similar to when I learned to touch-type. I did suffer, but productivity was increased tenfold in the end.
IMHO, you're not a user to require UI friendliness. The difference between a developer and a user is that users are using these applications casually. But if your day job is depending on a text editor, you should use the text editor that stays the least in your way, and friendliness has nothing to do with it. Ditto for version control.
On a side-note, race-car drivers in general do not use automatic transmissions. That's because they can change gears more efficiently than a computer can and because they don't need to eat sandwiches while driving.
The analogy to text editors is bad though, since everyone can choose the UI they like for text editing, whereas for source control the choice of UIs is much reduced.
In other words, I can choose Vim/Emacs, slog away and get proficient, and someone else can read my code with notepad. With VCS, I'm asking casual and hardcore users to use the same UI, so it better appeal to both.
In other words, I can choose Vim/Emacs, slog away and get proficient, and someone else can read my code with notepad. With VCS, I'm asking casual and hardcore users to use the same UI, so it better appeal to both.
I am comfortable in Emacs and quite good with vim. Both do get in my way, which is why I moved to Sublime Text for text editing.
I don't live in my text editor. I spend most of my time in IntelliJ or Visual Studio. The conventions of normal text editors are largely established, and so something that runs counter to those normal conventions--an emacs or a vim--do get in my way. It is a mental gearshift to go "oh, I need to do something different now", which is a drain on my concentration and a way to get annoyed and off track because I tried to go Ctrl-A in Visual Studio and it didn't do what I wanted it to do. The productivity benefit of not having to make my brain go modal or instantly remap my mental keybindings to use emacs even outweighed losing the extensions I liked (vimwiki has been largely replaced by Evernote for me now).
And, yes, VS or IntelliJ are more important than my text editor. They win by default--"Well, use vim/emacs for everything!" is unacceptable for reasons that should be obvious. Vim and emacs are nonstandard at their own peril, and conforming to them is a worse use of my time than using something that conforms to expectations.
That you don't "get" how I can stand it is OK; the important thing is that I can.
I don't live in my text editor. I spend most of my time in IntelliJ or Visual Studio. The conventions of normal text editors are largely established, and so something that runs counter to those normal conventions--an emacs or a vim--do get in my way. It is a mental gearshift to go "oh, I need to do something different now", which is a drain on my concentration and a way to get annoyed and off track because I tried to go Ctrl-A in Visual Studio and it didn't do what I wanted it to do. The productivity benefit of not having to make my brain go modal or instantly remap my mental keybindings to use emacs even outweighed losing the extensions I liked (vimwiki has been largely replaced by Evernote for me now).
And, yes, VS or IntelliJ are more important than my text editor. They win by default--"Well, use vim/emacs for everything!" is unacceptable for reasons that should be obvious. Vim and emacs are nonstandard at their own peril, and conforming to them is a worse use of my time than using something that conforms to expectations.
That you don't "get" how I can stand it is OK; the important thing is that I can.
I spend most of my time in IntelliJ or Visual Studio.
True anecdote - whenever I'm working with Eclipse, I have a shortcut that opens the current file in Emacs for me.
Vim and emacs are nonstandard at their own peril
That you don't "get" how I can stand it is OK;
the important thing is that I can.
Yeah, I don't have those people in any meaningful capacity. If I did then hg would immediately be a strong contender.
With regards to the philosophical difference, I see where you're coming from. This is the reason I use OS X instead of Linux for instance, it's more important for me to have a simple and usable GUI than to have ultimate control and flexibility. With text editors and version control systems I don't feel that way though. As a matter of fact, I do use vim, and I don't think it's ridiculous in the least to use tools that require "grokking" for one's core competency. I'm not saying everyone should use these tools, but I do believe in my heart that the power of vim can not be equalled by a more user-friendly text editor. Sure you can have a more powerful IDE for language X or Y, but I doubt any of those will be able to stick around and grow with me over the dozens of languages I will use over the course of my career. Since I plan to use these tools for decades (unlike programming languages themselves), the importance of newbie-friendliness approaches zero. That's not to say the UI doesn't matter, but just that the factors that matter are the ones that are applicable to the master rather than the apprentice.
With regards to the philosophical difference, I see where you're coming from. This is the reason I use OS X instead of Linux for instance, it's more important for me to have a simple and usable GUI than to have ultimate control and flexibility. With text editors and version control systems I don't feel that way though. As a matter of fact, I do use vim, and I don't think it's ridiculous in the least to use tools that require "grokking" for one's core competency. I'm not saying everyone should use these tools, but I do believe in my heart that the power of vim can not be equalled by a more user-friendly text editor. Sure you can have a more powerful IDE for language X or Y, but I doubt any of those will be able to stick around and grow with me over the dozens of languages I will use over the course of my career. Since I plan to use these tools for decades (unlike programming languages themselves), the importance of newbie-friendliness approaches zero. That's not to say the UI doesn't matter, but just that the factors that matter are the ones that are applicable to the master rather than the apprentice.
I never said "newbie-friendliness," though I can see how that might have been implied by my last post. I said "user-friendliness", which I think also lends itself to easier uptake from novices. Sorry for the confusion.
I know vim quite well. I still consider it onerous and unpleasant to use, and I find claims of its "power" to be overstated; I have noted before and still think to be true that editing text isn't the hard part of my job. I am definitely suspicious of claims that "it'll still be there in ten years" to be hugely important; my editor might change in ten years, but Cmd-X will still be cut and Cmd-V will still be paste, you know what I mean? The specifics of exactly what text editor I use matter so much less to me than "does it not make me hate using it?".
All of that is an aside, however, and tangential to what I was saying: for me, the visceral reaction to both vim and git is not a pleasant one; I find them to be designed for people whose mental model with regards to computer interaction is alien to mine, and despite being capable with both I find such tools uncomfortable to use. I don't consider either user-friendly (and, I think, to most people), and while I don't begrudge those who prefer those tools, life is simply too short to spend my time squeezing blood out of that particular stone.
I know vim quite well. I still consider it onerous and unpleasant to use, and I find claims of its "power" to be overstated; I have noted before and still think to be true that editing text isn't the hard part of my job. I am definitely suspicious of claims that "it'll still be there in ten years" to be hugely important; my editor might change in ten years, but Cmd-X will still be cut and Cmd-V will still be paste, you know what I mean? The specifics of exactly what text editor I use matter so much less to me than "does it not make me hate using it?".
All of that is an aside, however, and tangential to what I was saying: for me, the visceral reaction to both vim and git is not a pleasant one; I find them to be designed for people whose mental model with regards to computer interaction is alien to mine, and despite being capable with both I find such tools uncomfortable to use. I don't consider either user-friendly (and, I think, to most people), and while I don't begrudge those who prefer those tools, life is simply too short to spend my time squeezing blood out of that particular stone.
> but Cmd-X will still be cut and Cmd-V will
> still be paste
> Git requires you to accept certain behaviors and the cultural encouragement of same, e.g. rewritable history, of which I'm very much not a fan.
I've seen this opinion espoused by others and I just don't understand it. I'd never ever use a VCS anymore that didn't let me "rewrite history". "git filter-branch" has saved me many hours of commit-work on multiple occasions--I just can't see why not having those kind of tools is considered a good thing.
Bzr is adamantly anti-amend and now the main Emacs repo has 10 megs of binary junk in the history that some developer accidentally checked in and pushed one day. Tell me why that is a good thing?
I've seen this opinion espoused by others and I just don't understand it. I'd never ever use a VCS anymore that didn't let me "rewrite history". "git filter-branch" has saved me many hours of commit-work on multiple occasions--I just can't see why not having those kind of tools is considered a good thing.
Bzr is adamantly anti-amend and now the main Emacs repo has 10 megs of binary junk in the history that some developer accidentally checked in and pushed one day. Tell me why that is a good thing?
But look at it this way: What would github gain by adding mercurial support?
They're insanely popular and becoming more so by the minute, and their biggest problems probably have to do with managing growth, not lack of users. With git itself becoming increasingly popular, there's absolutely no sense that git will be a limiting factor any time in the future.
They clearly do recognize the long-term advantages in improving the usability of git, and have been making moves in that direction (iphone client, increasing the functionality of their web interface, some interaction on the git dev list), but hg's purported UI advantages are tenuous at best, and it seems a much surer bet to consolidate their position and improve git instead of investing a lot of effort in supporting hg, which would only _dilute_ their position.
They're insanely popular and becoming more so by the minute, and their biggest problems probably have to do with managing growth, not lack of users. With git itself becoming increasingly popular, there's absolutely no sense that git will be a limiting factor any time in the future.
They clearly do recognize the long-term advantages in improving the usability of git, and have been making moves in that direction (iphone client, increasing the functionality of their web interface, some interaction on the git dev list), but hg's purported UI advantages are tenuous at best, and it seems a much surer bet to consolidate their position and improve git instead of investing a lot of effort in supporting hg, which would only _dilute_ their position.
Exactly, GitHub is to Git as Rails is to Ruby.
Free unlimited private repos for up to 5 users; with competition like that maybe we'll see github improve it's pricing.
I doubt it. There is no need for them to, they aren't hurting or struggling.
Running businesses with "lets offer more for free" and "ohh crap, they offer more for free, lets lower our price" is a race to the bottom.
It is actually moves like these that make me question Bitbucket more. How viable is the service long term? Do I want to trust all my own code to them?
Running businesses with "lets offer more for free" and "ohh crap, they offer more for free, lets lower our price" is a race to the bottom.
It is actually moves like these that make me question Bitbucket more. How viable is the service long term? Do I want to trust all my own code to them?
You sound like an apple customer, you get more for same price and consider this a bad thing... Pigs indeed fly.
It doesn't cost them a lot more in infrastructure to provide alternate dvcs - so your point seems to be completly invalid. More and more I'm starting to think that git is some kind of religion.
We benefit from competition between those 2 platforms and in the end this is what should count the most for us - customers.
It doesn't cost them a lot more in infrastructure to provide alternate dvcs - so your point seems to be completly invalid. More and more I'm starting to think that git is some kind of religion.
We benefit from competition between those 2 platforms and in the end this is what should count the most for us - customers.
It's amazing that your comment got thumbed down, not up. All points seem perfecly valid, so it really must be the "Apple customer" reference that killed it. Sad.
What's sad is the absurd claim that Apple customers believe that getting more for the same price is a bad thing. As for the next point, whether providing alternative DVCS access leads to greater fixed infrastructure costs or not, that seems like a completely orthogonal point to the "race to the bottom" topic that the OP raised. If all players involved reduce their prices (and therefore top-line revenue) to near zero, it doesn't matter how low the infrastructure costs are -- everyone is still broke in that scenario. So no, not all points here seem valid. Far from it: by my count, it looks like 0 for 2 so far.
One point, however, rings true: competition is good for we end-users, and it's certainly exciting that Bitbucket now offers both hg and git access.
One point, however, rings true: competition is good for we end-users, and it's certainly exciting that Bitbucket now offers both hg and git access.
[deleted]
Why would you claim that someone reduced their prices and revenue to zero? How does providing additional functionality relate to price reduction? I'm really surprised by this comment - do you have any data to base this assumption?
To me it's opening to customers with different demands.
To me it's opening to customers with different demands.
Yes, I am an Apple customer, though really don't think that has anything to do with it.
My opinion stems from running my own SaaS applications, seen the business downsides of all the free stuff, and now don't focus very much on the free aspect. I prefer trial.
I also recognize that me paying for a service I like is a healthy way to help that service stay around, because that is how I view it when my customers are paying me.
My opinion stems from running my own SaaS applications, seen the business downsides of all the free stuff, and now don't focus very much on the free aspect. I prefer trial.
I also recognize that me paying for a service I like is a healthy way to help that service stay around, because that is how I view it when my customers are paying me.
Bitbucket is funded by Atlassian - their other products have a huge install base at enterprises across the world. Atlassian could probably run Bitbucket at a loss as marketing if they wanted to
And if my hunch is right, that's what they do right now.
Why? They still charge per user, and multi-user private account is what companies look for. Really, I don't believe that GitHub relies on profit from personal side projects. It's also companies they are after.
Since Bitbucket is based on DVCSes, you won't actually lose any of your code even if they do go under, so it's probably a better question if you trust them with your issue tracking than with your code.
Sure, its DVCS, but if they go away, where will you host it now?
You are choosing to use Bitbucket for specific reasons. If they shut down because Atlassian is burning money and wants to trim the bottom line, then you now need to find something else to fill those specific needs again.
You don't lose any code, but you now need to figure something else out. And if you were relying on "free unlimited private repositories" you might not find that on another and now have to pay for something else.
Personally, I use GitHub daily for my job, but my private code isn't with GitHub.
You are choosing to use Bitbucket for specific reasons. If they shut down because Atlassian is burning money and wants to trim the bottom line, then you now need to find something else to fill those specific needs again.
You don't lose any code, but you now need to figure something else out. And if you were relying on "free unlimited private repositories" you might not find that on another and now have to pay for something else.
Personally, I use GitHub daily for my job, but my private code isn't with GitHub.
> where will you host it now?
On any available machine with some free space and an SSH daemon?
You talk about "figuring something else out" like it's some sort of big project. I don't understand that at all. There's no really effective lock-in here, users can take their repos and go anywhere or nowhere with negligible effort. They could even easily maintain a full copy of their repos on some backup machine at all times while using bitbucket or github.
On any available machine with some free space and an SSH daemon?
You talk about "figuring something else out" like it's some sort of big project. I don't understand that at all. There's no really effective lock-in here, users can take their repos and go anywhere or nowhere with negligible effort. They could even easily maintain a full copy of their repos on some backup machine at all times while using bitbucket or github.
[deleted]
They one thing they could to make it a lot better, is to allow a few (5-8 maybe?) private zero-collaborator repos in the free plan.
And they can always increase the number of repos in each plan. I understand this won't make them as competitive on pricing, but the better user experience they offer has to be reflected in the cost.
And they can always increase the number of repos in each plan. I understand this won't make them as competitive on pricing, but the better user experience they offer has to be reflected in the cost.
As a daily Bitbucket user, I appreciate their efforts. But unfortunately I don't see improvement on navigation. It's quite painful to browse source code via web. If I just want to quickly look at someone's repository, I will make a lot of browsing, and it's just way too slow.
Compare it to Github's slick UI: https://github.com/blog/760-the-tree-slider
But I am optimistic Bitbucket will change it for the better.
Compare it to Github's slick UI: https://github.com/blog/760-the-tree-slider
But I am optimistic Bitbucket will change it for the better.
(I'm a Bitbucket developer.)
I completely agree that UI's something we need to improve on. I do think we've been making progress: We recently redesigned the commit history page, we've cleaned up the repository and account admin pages, and we've been updating the whole site with a more streamlined look and feel.
One of the next big things on our roadmap is redoing the repository header (that thing with all the tabs and buttons). And personally, I'd like to see us standardize on a single repo landing page with everything you need, but that's a little controversial at the moment. :)
We're huge fans of defunkt's pjax library, so expect to see it used more on the site in the future - including in the source browser.
Oh, and we're currently looking for a designer! http://www.atlassian.com/about/careers/listing.jsp?jobID=143
I completely agree that UI's something we need to improve on. I do think we've been making progress: We recently redesigned the commit history page, we've cleaned up the repository and account admin pages, and we've been updating the whole site with a more streamlined look and feel.
One of the next big things on our roadmap is redoing the repository header (that thing with all the tabs and buttons). And personally, I'd like to see us standardize on a single repo landing page with everything you need, but that's a little controversial at the moment. :)
We're huge fans of defunkt's pjax library, so expect to see it used more on the site in the future - including in the source browser.
Oh, and we're currently looking for a designer! http://www.atlassian.com/about/careers/listing.jsp?jobID=143
To me, the biggest Bitbucket UI issue isn't the lack of some of Github's snazziness, but the simple lack of visual cues to separate elements on the page.
See: https://bitbucket.org/ellislab/codeigniter-reactor/
Every major block element on that page except for the very top page navigation has a white background. The project info box has a white background, the branches/tags/etc controls bar has a white background, the commit table has a white background, the footer has a white background - all matching (and failing to stand out from) the page's own white background.
Compare to: https://github.com/rails/rails
The use of varying grays and even a blue background help separate elements from each other, as well as separate them from the page background that they're on top of.
I'm not a designer, but the one thing that has always turned me off from Bitbucket is feeling like I'm looking at a bunch of visual clutter whenever I first look at a page. And it's not because there is a lot of visual clutter (there isn't) but simply because everything on the whole page is on the same white background and, at first glance, just blurs into each other.
See: https://bitbucket.org/ellislab/codeigniter-reactor/
Every major block element on that page except for the very top page navigation has a white background. The project info box has a white background, the branches/tags/etc controls bar has a white background, the commit table has a white background, the footer has a white background - all matching (and failing to stand out from) the page's own white background.
Compare to: https://github.com/rails/rails
The use of varying grays and even a blue background help separate elements from each other, as well as separate them from the page background that they're on top of.
I'm not a designer, but the one thing that has always turned me off from Bitbucket is feeling like I'm looking at a bunch of visual clutter whenever I first look at a page. And it's not because there is a lot of visual clutter (there isn't) but simply because everything on the whole page is on the same white background and, at first glance, just blurs into each other.
I am on bitbucket and have been for a long time. I've even bought some of your services for a project.
However, github's UI is really exceptional. Things like the slide-over really make it a smooth experience.
My feedback is that hg is solid, bitbucket guts are solid, and the UI is what's really holding you back (besides the git fanboys hollering really loudly).
However, github's UI is really exceptional. Things like the slide-over really make it a smooth experience.
My feedback is that hg is solid, bitbucket guts are solid, and the UI is what's really holding you back (besides the git fanboys hollering really loudly).
Yes please - small things like the branches drop down are not very intuitive.
I think the competitive advantage for Bitbucket will come from super-enhancing features like the issue tracker. Today, I still have to run Redmine inspite of having Github issues. Give me an industrial quality issue tracker (hooks, assignee features, charting, roles and permissions).
Basically just pull Bugzilla into Bitbucket. Now, that would be a killer feature !
I think the competitive advantage for Bitbucket will come from super-enhancing features like the issue tracker. Today, I still have to run Redmine inspite of having Github issues. Give me an industrial quality issue tracker (hooks, assignee features, charting, roles and permissions).
Basically just pull Bugzilla into Bitbucket. Now, that would be a killer feature !
Please, NO. I would cringe at a full version of Jira being included, too. If I want one of those, I will install one of them. I do think BB's issues are under-powered (and it is a major problem), but I'd much rather have a clean, clear, well-designed 20% of Jira.
In BB's defense, GH's issue system is horribly underpowered too.
Really? Bugzilla? Talking about bad user interfaces. Anyway I don't see the BitBucket guys integrating Bugzilla anytime soon since they're part of Atlassian now which markets the Jira issue tracker.
Nope - I'm not really talking about Bugzilla or Jira from a UI point of view, but more of a functionality angle.
That's the thing - the UI for issue tracking, on both Github and Bitbucket, is great. No functionality however.
TL;DR : will pay for issues
TL;DR : will pay for issues
I am happy to hear this. Thank you! (for the pjax reference and great service)
The only reason I went with Bitbucket over Github for my own source control was the availability of free private repositories that Github charges for. Now I've got the best of both source control solutions!
store every line of code you’ve ever wrote in one place without paying a cent
Great news (and thanks)! However, please s/wrote/written/
EDIT: I see they fixed the copy.
Great news (and thanks)! However, please s/wrote/written/
EDIT: I see they fixed the copy.
Thanks for pointing this out.
Since we have your attention... :)
http://confluence.atlassian.com/display/BITBUCKET/Bitbucket+... - shows error message "Unable to render {include} The included page could not be found."
http://confluence.atlassian.com/display/BITBUCKET/Bitbucket+... - shows error message "Unable to render {include} The included page could not be found."
Thanks. As I'm sure you've guessed, this was a permissions problem with some of the pages we'd been keeping quiet until the launch. Let us know if you find any more.
I use GitHub mainly for private repos. I think I will actually move my private repos over to Bitbucket.
I really like GitHub Issues though. Does Bitbucket have anything similar? I don't see it on their site.
I really like GitHub Issues though. Does Bitbucket have anything similar? I don't see it on their site.
Bitbucket issues had a recent update (only noticed it today myself) and it's much improved. It's a little basic but it fits my needs pretty well.
You can see one at https://bitbucket.org/jespern/django-piston/issues?status=ne...
You can see one at https://bitbucket.org/jespern/django-piston/issues?status=ne...
Oh wow, that is an improvement. Their issue UI used to be pretty bad. I'm glad they've improved it so much. Might be time to re-evaluate using it.
Atlassian (which recently acquired Bitbucket) is well known forJira/Confluence.
Could it be that if they might use Bitbucket as an entry point to their products? Perhaps with more integration.
Could it be that if they might use Bitbucket as an entry point to their products? Perhaps with more integration.
It seems as if they've already released a fairly simple plugin to integrate Bitbucket with JIRA, which is nice. I'd personally like to see deeper integration between Bitbucket and Atlassian products like Crucible, JIRA, Confluence, etc.
Although I can see the many possible integrations between Crucible, JIRA and BitBucket, I'd love to hear if you have any thoughts on Confluence and BitBucket integration. Right now you can quickly view the contents of a BitBucket repo from a Confluence page: https://plugins.atlassian.com/plugin/details/40188
perhaps they should update the web site:
=== Thank you for signing up for Bitbucket!
You are currently on the 5 Users plan. You can always upgrade your plan to add more collaborators.
We're excited that you're getting started with Mercurial, arguably the best distributed version control system around. We've put together some great resources to get you up and running quickly so that your team can focus on building great software faster.
Cheers, The Atlassian Bitbucket team ===
=== Thank you for signing up for Bitbucket!
You are currently on the 5 Users plan. You can always upgrade your plan to add more collaborators.
We're excited that you're getting started with Mercurial, arguably the best distributed version control system around. We've put together some great resources to get you up and running quickly so that your team can focus on building great software faster.
Cheers, The Atlassian Bitbucket team ===
I looked at this and thought "this is like Github, but not as good"
If you're even semi-serious about development, paying $7/month is nothing for the value they provide.
If you're even semi-serious about development, paying $7/month is nothing for the value they provide.
Any semi-serious developer is going to use up the 5 private repos really quickly. 20 repos ($22/mo) is easily achievable for anyone who likes side-projects, and after that, larger plans are only "available on request".
I wouldn't expect GitHub to compete directly with BitBucket's pricing, but doubling the amount of private repos allowed wouldn't hurt.
I wouldn't expect GitHub to compete directly with BitBucket's pricing, but doubling the amount of private repos allowed wouldn't hurt.
Many serious developers opt to keep as much of their source open as they can. It's not uncommon to find dozens of public side projects in the repository list of Github users. Occasionally someone will stumble on something interesting and collaborators will sprout. This is far less common on Bitbucket.
Github's pricing policy seems to strongly encourage community and collaboration, and it works wonders.
Github's pricing policy seems to strongly encourage community and collaboration, and it works wonders.
Seriously. I always find it funny when people make generalizations like "Any serious developer would..." only to be 100% wrong (and thus proving that they aren't serious developers).
I used to think like your parent. Then I got over myself and just push everything to a a public github repo. So what if most of my project have no watchers and no forks. It can't hurt anything (except maybe my ego?). Once I did the transition with one of my bigger projects, I've nerver looked back.
Private repositories are for "serious" companies. Public repository are for "serious" developers.
I used to think like your parent. Then I got over myself and just push everything to a a public github repo. So what if most of my project have no watchers and no forks. It can't hurt anything (except maybe my ego?). Once I did the transition with one of my bigger projects, I've nerver looked back.
Private repositories are for "serious" companies. Public repository are for "serious" developers.
As a student I make regular use of private repos because publishing answers to marked coursework is frowned upon.
This is largely true when you graduate as well. I still have all my grad coursework in git and find it useful to reference, but don't want to make public due to academic dishonesty.
I'd love to hear more about this academic dishonesty. I've been disconnected from academia for a long time.
For me, I specifically make a lot of my work public to avoid someone else claiming sole invention rights--as I have reasonable public proof of prior art. Though to this day this has never happened, and people have always given my projects more than appropriate credit without even having to ask.
For me, I specifically make a lot of my work public to avoid someone else claiming sole invention rights--as I have reasonable public proof of prior art. Though to this day this has never happened, and people have always given my projects more than appropriate credit without even having to ask.
Having served as a TA, I can assure you some students will seek out anything tangentially related and make few if any modifications to the project. This isn't just a case of reused projects, too. A lot of times our assignments would be open-ended within a framework (e.g., create a game that uses the minimax algorithm). Things like that. And naturally they seek out anyone that had taken the class previously.
It really depends on the type of side projects a developer does.
If it has something to do with their main business (say something to manage their server commands easily) or is integrated into another one of their tools the cost open sourcing it may not be worth it.
If it has something to do with their main business (say something to manage their server commands easily) or is integrated into another one of their tools the cost open sourcing it may not be worth it.
[deleted]
[deleted](1)
I'm not sure why my ability to run my own Git server or use a provided hosted Git solution regardless of it's name affects the seriousness of my programming ability.
This is great news and I hope it helps do all that others are saying, like improve pricing.
I've had a Bitbucket account for a while and never used it, mainly because I'm more comfortable with git. But after poking around Bitbucket and importing some repos I'm seeing that you really get what you pay for.
GitHub completely trounces Bitbucket with their ease of use and toolset. I hope Bitbucket can step it up.
I've had a Bitbucket account for a while and never used it, mainly because I'm more comfortable with git. But after poking around Bitbucket and importing some repos I'm seeing that you really get what you pay for.
GitHub completely trounces Bitbucket with their ease of use and toolset. I hope Bitbucket can step it up.
This has probably been asked before, but is Bitbucket really unlimited?
If I encrypt my drive, convert it to ASCII, and upload it, will they host it?
If I encrypt my drive, convert it to ASCII, and upload it, will they host it?
No it is not considered fair use[1] from the CEO of Atlassian[2].
[1] http://news.ycombinator.com/item?id=3068576
[2] Unconfirmed by me. http://news.ycombinator.com/item?id=3067107
[1] http://news.ycombinator.com/item?id=3068576
[2] Unconfirmed by me. http://news.ycombinator.com/item?id=3067107
give it a try and tell us, probably no one tried this one yet ;-)
Good luck committing an image of your hard drive into git or hg.
Seriously, though, the limitations of git and mercurial with respect to large files probably prevent them from having to deal with this kind of thing.
Seriously, though, the limitations of git and mercurial with respect to large files probably prevent them from having to deal with this kind of thing.
https://github.com/apenwarr/bup can help split a big image into many smaller pieces.
Why upload your drive when you could just mount the dvcs as a drive?
https://github.com/mfontani/git-fuse-perl
https://github.com/mfontani/git-fuse-perl
I signed up for Bitbucket the instant they had git availability. I only started using Git regularly for new/small projects a month ago, after quite happily using svn for web projects.
Bitbucket gets what I need. I love the social coding of GitHub and will continue to participate in it. But I can't put my own projects there. There's too many small, private repos that I can't keep paying for.
Bitbucket's approach is good for me. I'd rather pay for storage/users than per repo. If Github is really about promoting source code control, it shouldn't be a barrier for private / personal projects. For now, bitbucket solves this. I hope Github comes around.
Until then, I'm cancelling my $7 github account and giving Bitbucket $10/month even though I'm only using 2 users. They're doing me a real service and favor.
Bitbucket gets what I need. I love the social coding of GitHub and will continue to participate in it. But I can't put my own projects there. There's too many small, private repos that I can't keep paying for.
Bitbucket's approach is good for me. I'd rather pay for storage/users than per repo. If Github is really about promoting source code control, it shouldn't be a barrier for private / personal projects. For now, bitbucket solves this. I hope Github comes around.
Until then, I'm cancelling my $7 github account and giving Bitbucket $10/month even though I'm only using 2 users. They're doing me a real service and favor.
I'm now a BitBucket user. I'll keep using GitHub for my open source stuff, but you betcha that my private repos are going on BitBucket. I'd love to see GitHub step up and compete here, but I'm really perfectly happy to use two products for two different use cases.
This was exactly what I was thinking
Git is the same, moving a Git repo from bitbucket to github shouldn't be an issue
bitbucket for your private repos, promote to github for when they become open-source to benefit from the larger community
i believe github might end up charging for public repos, rather than reducing the prices for private ones ;)
bitbucket for your private repos, promote to github for when they become open-source to benefit from the larger community
i believe github might end up charging for public repos, rather than reducing the prices for private ones ;)
They announced Git support in 2009 also, but that was an April Fool's joke. Link to that post: http://blog.bitbucket.org/2009/04/01/announcing-git-support/
I just checked and none of my existing Bitbucket repos have a Git link, nor can I find a way to add Git support from the Admin screen. However when I go to add a new repo Git is an option.
Please tell me (frown face) that this feature isn't just for new repos....
Please tell me (frown face) that this feature isn't just for new repos....
When we were prototyping Git support, one of the first things we investigated was having automatic conversion between Hg and Git on the server. We weren't able to get the performance to a level where responsiveness would be acceptable, and maintaining consistency between the two repos was complex.
It's something we might revisit in the distant future. As a middle ground, I've been thinking of implementing support for multiple SCMs in a single repository with the conversion/syncing process left up to the user. But that'll probably take more than a couple of 20% days to bang out. :)
If you're interested, I have some patches against hg-git that make it easier to take an existing Hg repo and convert it to Git (as opposed to the other way around). I haven't had a chance to prepare them to go upstream yet, but my repo's here: [link redacted]
It's something we might revisit in the distant future. As a middle ground, I've been thinking of implementing support for multiple SCMs in a single repository with the conversion/syncing process left up to the user. But that'll probably take more than a couple of 20% days to bang out. :)
If you're interested, I have some patches against hg-git that make it easier to take an existing Hg repo and convert it to Git (as opposed to the other way around). I haven't had a chance to prepare them to go upstream yet, but my repo's here: [link redacted]
I don't care about converting my code, I'll just delete the .hg directories, I care about having to create new repos MyProject2, MyOtherProject2
They have not implemented seamless conversion from hg repos to git repos. However, there exist tools to do that: http://hedonismbot.wordpress.com/2008/10/16/hg-fast-export-c...
Definitely going to give this a go. I have a lot of repos I'd like to keep private, but they're mostly personal projects and not worth paying more money for at GitHub.
Quick question from someone new to Bitbucket:
I have to authenticate every time I push to the repo. I've added my SSH key to the account, but I assume there's some additional configuration, such as how github has you add values for github.user and github.token to your global git config, but I can't find any such info for what those variables need to be for Bitbucket - assuming that's the reason I'm still continually prompted for a password.
Has anyone sorted this out yet or got SSH authentication working with Git & Bitbucket?
Quick question from someone new to Bitbucket:
I have to authenticate every time I push to the repo. I've added my SSH key to the account, but I assume there's some additional configuration, such as how github has you add values for github.user and github.token to your global git config, but I can't find any such info for what those variables need to be for Bitbucket - assuming that's the reason I'm still continually prompted for a password.
Has anyone sorted this out yet or got SSH authentication working with Git & Bitbucket?
Make sure to use [email protected]:{username}/{reponame} instead of any https links bitbucket might give you.
I was able to upload an existing repo I had by:
1) Uploading my SSH Public Key at https://bitbucket.org/account/ (i.e. the contents of ~/.ssh/id_rsa.pub) 2) Create a blank repo at Bitbucket 3) Adding a remote (git remote add bitbucket [email protected]:{username}/{reponame}.git) 4) Pushing to bitbucket (git push bitbucket master)
The most important parts were adding my SSH Public Key, and making sure to use [email protected]:{username}/{reponame}.git instead of any https links you might see on bitbucket.
I was able to upload an existing repo I had by:
1) Uploading my SSH Public Key at https://bitbucket.org/account/ (i.e. the contents of ~/.ssh/id_rsa.pub) 2) Create a blank repo at Bitbucket 3) Adding a remote (git remote add bitbucket [email protected]:{username}/{reponame}.git) 4) Pushing to bitbucket (git push bitbucket master)
The most important parts were adding my SSH Public Key, and making sure to use [email protected]:{username}/{reponame}.git instead of any https links you might see on bitbucket.
Ah, thanks so much! That makes perfect sense. I was using the https link that bigbucket provided initially.
ack
thanks!
I wonder why these info are not widely written around the web...
The github.user and github.token settings aren't used by git, by the way - they're used by any tools you might use that can use the github API. They aren't required for pushing or pulling over ssh.
I just signed up for a free account and already made 6 private git repos. Nice.
I must say that I wish there was a middle road between bitbucket and github pricing: I like to pay enough money to to be fair. I will eventually have about 20 small repos, most of which I won't use very often. Solo developer.
It would not cost much at all to support a user such as myself, so if the cost were about $5/month that would be better than free. That said, it is so easy to move git hosting back to one of my EC2s, that if they decide to not provide this service in the future it is only a small hassle.
I must say that I wish there was a middle road between bitbucket and github pricing: I like to pay enough money to to be fair. I will eventually have about 20 small repos, most of which I won't use very often. Solo developer.
It would not cost much at all to support a user such as myself, so if the cost were about $5/month that would be better than free. That said, it is so easy to move git hosting back to one of my EC2s, that if they decide to not provide this service in the future it is only a small hassle.
While this is great news, I really don't need an interface for sideprojects (yet). Codeplane's been great so far for private repos.
I just backed up my Github stuff using Github-backup and added them to Codeplane. Honestly surprised nobody challenged GitHub in pricing until recently. As far as social coding goes they are the Facebook of repo hosting (SourceForge is Friendster and Google Code is MySpace).
https://github.com/ddollar/github-backup
http://codeplane.com/
I just backed up my Github stuff using Github-backup and added them to Codeplane. Honestly surprised nobody challenged GitHub in pricing until recently. As far as social coding goes they are the Facebook of repo hosting (SourceForge is Friendster and Google Code is MySpace).
https://github.com/ddollar/github-backup
http://codeplane.com/
[deleted]
I was using unfuddle.com just to get a single private repository (didn't want to pay $10 a month for that on github). This is great news.
I'm in exactly the same position, and will now proceed to move all private repos over to bitbucket.
Great to see bitbucket expanding the offering.
A while back I had chosen bitbucket over GitHub because of the free private repository. And Git was not an absolute requirement, non-Git source control was absolutely fine.
GitHub still does not offer a private repo for free (currently private is $7/month), I imagine this may change at some point soon now.
A while back I had chosen bitbucket over GitHub because of the free private repository. And Git was not an absolute requirement, non-Git source control was absolutely fine.
GitHub still does not offer a private repo for free (currently private is $7/month), I imagine this may change at some point soon now.
I still use an installation of Gitosis on my VPS to host my small private git projects. As long as you have a unix-ey box then it's very easy to set it up. Though I would definitely upload public projects to Github, for the community and visibility aspect of it.
Hopefully this is a wakeup call for the Github guys and they start working on their business instead of just the product. This is a great start: http://fi.github.com/
[deleted]
This is really good news.
The greatest strength they have over Github right now is unlimited private git repositories (github only allows 1 private repo for free accounts), free of charge.
The greatest strength they have over Github right now is unlimited private git repositories (github only allows 1 private repo for free accounts), free of charge.
How is this justified, to stay free?
True, it preps users for other Atlassian products; and marginal cost of storage is near-zero these days.
True, it preps users for other Atlassian products; and marginal cost of storage is near-zero these days.
I love bitbucket for the pricing it turned out to be a more valuable tool for my private repos. Now it is even better with git.
[deleted]
Blog post by schacon trash talking bitbucket in 3... 2... 1...
[deleted]
Bitbucket (a popular mercurial hosting site) has added git support.
Has any popular git hosting site added mercurial support?
This shows which DVCS is winning.
Has any popular git hosting site added mercurial support?
This shows which DVCS is winning.
Alternatively it shows which group cares about getting things done, rather than some software winning/losing.
It's a power grab, and we benefit from it.
There is no need for any DVCS to "win". Now you can use whatever you want without restrictions, why force others to use what you use?
(disclaimer - I'm the CEO of Atlassian)
Developers are religious. Whether it is vi vs emacs, or IDEA vs Eclipse or Mac vs Linux. In September we had a huge debate internally (hundreds of comments long) on functional vs non-functional programming.
We know that no-one wins in these religious debates.
We've found that developers are equally religious regarding their DVCS. Most frequently it is whatever DVCS you started with is the one that you're passionate about.
We've found that most companies of any size have both Git and Mercurial lurking somewhere in their development ranks. Previously if they wanted to host their code in the cloud (and who wouldn't), they would have had to choose two different hosting providers. As a developer, this was a pain as you never knew where your code was.
Now that Bitbucket supports both, you no longer have to choose. We think this is a huge win! Companies can store all their code in one place. And with the per-user pricing, it is a very fair pricing model (don't have to think about whether a fork is going to cost you or not!).
Developers are religious. Whether it is vi vs emacs, or IDEA vs Eclipse or Mac vs Linux. In September we had a huge debate internally (hundreds of comments long) on functional vs non-functional programming.
We know that no-one wins in these religious debates.
We've found that developers are equally religious regarding their DVCS. Most frequently it is whatever DVCS you started with is the one that you're passionate about.
We've found that most companies of any size have both Git and Mercurial lurking somewhere in their development ranks. Previously if they wanted to host their code in the cloud (and who wouldn't), they would have had to choose two different hosting providers. As a developer, this was a pain as you never knew where your code was.
Now that Bitbucket supports both, you no longer have to choose. We think this is a huge win! Companies can store all their code in one place. And with the per-user pricing, it is a very fair pricing model (don't have to think about whether a fork is going to cost you or not!).
If we had to re-make the decision of what remote DVCS host to use, I'd certainly look strongly at bitbucket. We have only a small handful of developers, but many repositories (60+) all getting low traffic.
We've used both Github and Beanstalkapp.com and both charge based on total repos rather then disk space or developers which, frankly, drives me a bit insane. I think both have better features then bitbucket (as far as I am aware) and better UI's (subjective) but my 60 small repos run me $100/month at beanstalk - not sure what it would run @ github.
I can't find any disk usage limits @ BB's site, which makes me wonder if there are hidden caps. If BB ever struck me as being as slick as github, I'd move our business in a second, even if the cost was higher then it is now ($10 a month? Really?!).
We've used both Github and Beanstalkapp.com and both charge based on total repos rather then disk space or developers which, frankly, drives me a bit insane. I think both have better features then bitbucket (as far as I am aware) and better UI's (subjective) but my 60 small repos run me $100/month at beanstalk - not sure what it would run @ github.
I can't find any disk usage limits @ BB's site, which makes me wonder if there are hidden caps. If BB ever struck me as being as slick as github, I'd move our business in a second, even if the cost was higher then it is now ($10 a month? Really?!).
Just as a FYI - we don't have any disk limits (apart from fair use).
We don't want our pricing to be based on repos, or disk space, or any other limitation that is hard to predict, or encourages sub-optimal decision making to optimise cost. We think that users is the best way to price a product, and is easy to predict.
In terms of UI - there are things that bug me today, but our team is cranking along improving it.
But we have found that most of our users spend their time interacting via the command-line, and therefore we have prioritised features around stability and performance, as well as enabling Git support. Now that this is done, we'll be focusing more time on UI again.
We don't want our pricing to be based on repos, or disk space, or any other limitation that is hard to predict, or encourages sub-optimal decision making to optimise cost. We think that users is the best way to price a product, and is easy to predict.
In terms of UI - there are things that bug me today, but our team is cranking along improving it.
But we have found that most of our users spend their time interacting via the command-line, and therefore we have prioritised features around stability and performance, as well as enabling Git support. Now that this is done, we'll be focusing more time on UI again.
Just as a FYI - we don't have any disk limits (apart from fair use).
Let me ask you about a particular case then :). I am in a group that develops a natural language parser for Dutch. It's open source, but so far we have been hosting it in a private Subversion repository on our university servers. We do provide a read-only (somewhat hidden) git mirror of the tree, but we have considered publishing it as an public git repository, but were always worried that the repository is too large for hosting it externally.
The git repository has existed for one and a half year, and the bare repo is currently 1098 MB in size*. Would hosting such a repository on Bitbucket be considered fair-use?
Let me ask you about a particular case then :). I am in a group that develops a natural language parser for Dutch. It's open source, but so far we have been hosting it in a private Subversion repository on our university servers. We do provide a read-only (somewhat hidden) git mirror of the tree, but we have considered publishing it as an public git repository, but were always worried that the repository is too large for hosting it externally.
The git repository has existed for one and a half year, and the bare repo is currently 1098 MB in size*. Would hosting such a repository on Bitbucket be considered fair-use?
It's fine. However, we would recommend pushing and pulling over SSH for speed.
And let me clarify: by fair-use we mean we offer unlimited _code_ hosting, not general storage. We monitor for abuse, such as large repos containing only music, videos, and public viruses or malware. Though don't worry - if we notice any problems we'd of course contact you first.
We'd love to have you as a customer!
And let me clarify: by fair-use we mean we offer unlimited _code_ hosting, not general storage. We monitor for abuse, such as large repos containing only music, videos, and public viruses or malware. Though don't worry - if we notice any problems we'd of course contact you first.
We'd love to have you as a customer!
Farkas, thank you for this information!
My company is currently debating between Github and Bitbucket. And the funny thing is git vs hg wasn't really an issue. We've decided that either is so much better than svn that we'd take either.
We have 2 large road blocks for Bitbucket. First is a real nice review system with inline comments during a pull request. Is this coming soon? It's an absolute deal breaker for us.
Also the performance/usability seems to be lacking compared to Github. I hope that changes. Although we also use JiraStudio and it's performance is dreadful. And the usability is quite frustrating. So the Atlassian track record is a little worrying for us.
We have 2 large road blocks for Bitbucket. First is a real nice review system with inline comments during a pull request. Is this coming soon? It's an absolute deal breaker for us.
Also the performance/usability seems to be lacking compared to Github. I hope that changes. Although we also use JiraStudio and it's performance is dreadful. And the usability is quite frustrating. So the Atlassian track record is a little worrying for us.
I really appreciate the feedback. Whilst I can't comment on future releases, I want to assure you that we are aware of the items you mention. Stay tuned :)
Yeah, I'm a happy developer that uses both bitbucket and github - I'd just wish that ui for bb gets nicer and more friendly - and it will be perfect tool for me.
<<Has any popular git hosting site added mercurial support?>>
Yes. In fact Github implemented the Git plugin for Mercurial that lets you use Github (or any Git repository) with Mercurial as your client rather than Git.
I guess this shows which DVCS is winning?
Yes. In fact Github implemented the Git plugin for Mercurial that lets you use Github (or any Git repository) with Mercurial as your client rather than Git.
I guess this shows which DVCS is winning?
As noted upthread, hg-git is a very poor facade.
The problem I have with git isn't in its syntax. It's in more central decisions with which I disagree fairly strenuously (I am very strongly in favor of indelible history, for example).
The problem I have with git isn't in its syntax. It's in more central decisions with which I disagree fairly strenuously (I am very strongly in favor of indelible history, for example).
Git history is indelible too. I mean, you can't mess with an existing tree without it being obvious.
But in any VCS you can of course start over. Set the system clock back and check the existing code from another repo into a new one in different chunks making it appear to have been made differently in the first place. There's no way around that other than signing your commits which would work in git as well...
But in any VCS you can of course start over. Set the system clock back and check the existing code from another repo into a new one in different chunks making it appear to have been made differently in the first place. There's no way around that other than signing your commits which would work in git as well...
This shows which DVCS is winning.
Why on earth, in the software world, taste / choice diversity is immediately considered as a war?
There is the editors war, DVCS war, OS war, Browsers war.
Let's give peace a chance!
Beanstalk (http://beanstalkapp.com) has added Mercurial to our Git and SVN support - it's in private beta right now, but you can email me [email protected] if you're interested in being added.
Google Code, and Microsoft's CodePlex have, yes.
Oops...I mis-read your question. I thought you asked "Has any popular hosting site added mercurial support?"
At least Google Code supports git for some time already. :)
http://google-opensource.blogspot.com/2011/07/announcing-git...
http://google-opensource.blogspot.com/2011/07/announcing-git...
I wonder if/how GitHub will respond. I strongly prefer their UI and already have a paid plan, but I find myself shuffling repos within the confines of that plan rather than stomaching the (admittedly not very big) upgrade cost since many of the projects aren't super important. I understand why they do it, but I just don't like that they place an arbitrary restriction on the number of private repos.