Live data from Hacker News

Introducing the Redesigned Bitbucket

blog.bitbucket.org

241–250 of 292 posts

Re: Introducing the Redesigned Bitbucket

#241
post #87

Earlier quoted context omitted.

free private repositories for small teams is a great way to draw people in. Same thing here. I used to pay for github for a private repo for code to a couple of apps I sell. Once I found BB, it was a no brainer to switch over.

If free private repos is the only thing that BitBucket offers over GitHub, then they'll not be in business for long. You cost them money.

Until your team grows above 5 people, at which point you make them money. The loss-leader is a tried and true business model.

Re: Introducing the Redesigned Bitbucket

#242
post #238

Earlier quoted context omitted.

Can someone explain whats the catch ? Looks like I can host my $22 github account for free on bitbucket.

there is no catch. their business model is not on repo count, but collaborators count. in other words, solo devs and very small teams can freeride, if you grow bigger you start paying. also, it's backed up by Atlassian.

I wouldn't say Atlassian is an asset. Jira is horrible.

Re: Introducing the Redesigned Bitbucket

#243
post #188

Earlier quoted context omitted.

Bitbucket had a pretty easy time of winning my business: free private repositories for small teams is a great way to draw people in.

It also integrates with several atlassian products, namely Jira which in my opinion beats github's issue tracker into the dust.

Does it integrate with Pivotal Tracker? Jira is a pain in the ass.

Re: Introducing the Redesigned Bitbucket

#244
post #19
post #5

I'm having trouble thinking of reasons why bitbucket is used so much less than github - or at least why it seems that way. It's looking pretty damn good to me right now!

Traction. But BitBucket will continue to get better, and Atlassian doesn't produce shit products.

Maybe it is just the installations I have had to use in the past (Possibly installed on slow computers or requiring too many custom fields etc) but as an issue reporter I loath JIRA as a slow and clunky issue tracker which also makes finding issues annoying.

Maybe it has wonderful features for the developer side but I haven't used that part of it so I cannot comment.

Whenever I go to report a bug on a project and find out they have JIRA I shudder.

Re: Introducing the Redesigned Bitbucket

#245
post #238

Earlier quoted context omitted.

there is no catch. their business model is not on repo count, but collaborators count. in other words, solo devs and very small teams can freeride, if you grow bigger you start paying. also, it's backed up by Atlassian.

I wouldn't say Atlassian is an asset. Jira is horrible.

I take great issue with that statement ;)

Re: Introducing the Redesigned Bitbucket

#246
post #178
post #173

Earlier quoted context omitted.

I would prefer if they would tie their pricing to the size of a repository or the number of collaborators, but not the number of repos. I have a paid account that I would like to dump a lot of old projects that I hardly ever change. I would have to upgrade to "large" and even that one wouldn't fit all the projects. Right now the solution is to either not host it with them or use something like Bitbucket.

definitely. hobbyists tend to run to "lots of small repos with low activity on any given one", but the net resource usage is the same as or lower than "a few big repos". per-repo pricing is more a "pay not to be inconvenienced" than "pay for your use of our resources" thing.

For the many-small-repo scenario, I use this technique to host multiple projects under one Github private repository:

http://stackoverflow.com/questions/1384325/in-git-is-there-a...

Instead of creating a repo per project, I create a orphan branch within a shared repo for that project. The benefit of this approach is that you can always cleanly export the commits into its own repository without altering SHA ids. The con is that you have to pick separate branch names for each project (e.g. proj1-master, proj2-master).

Re: Introducing the Redesigned Bitbucket

#247
post #26

Earlier quoted context omitted.

Yep. That's pretty much the focus of google code.

Not yet it isn't. In the current UI, to get to the source code, you have to 1. Find the little "Source" link and click it. 2. Find the "Browse" link, which is in a little toolbar right under the other little toolbar, next to the (less relevant) "Changes" and "Clones" links, which look visually near-identical. 3. In most (but not all) projects, hunt down the word "trunk" in tiny 13px text, and click it to see the main…

> but I've been wanting to rant about this UI failure for a while now. And don't even get me started on Launchpad.

After five years or whatever of being tricked into clicking Launchpad links, I just noticed the other day that they have a "source" link on the top left corner. I had no idea they actually displayed source code. I always thought it was some crappy bug reporting product. Who knew?

Re: Introducing the Redesigned Bitbucket

#249

Earlier quoted context omitted.

Can you repro that?

Can I repro giving the Github client to newbies and getting desperate pleas for help soon afterwards? Yes, it's consistent :-) No, I have not tried to reproduce the incidents which screwed up my repository. After a few harrowing experiences I pretty much gave up using the Github for Mac client for anything except basic commits. And even that screws up - I frequently have to commit files twice; it's like the client on…

It... really shouldn't be doing that. What is your precise workflow?
Post reply on HN