Code Repository Atlassian Buys Competitor BitBucket 150
Roblimo writes "Wow. Atlassian sent press releases out about this, and we're happy for them. But isn't Git easy to install and use — for free, even if your project is proprietary and secret, not open source and public? Whatever. Some people seem to feel better about proprietary software than about FOSS, and the majority of Atlassian's business comes from meeting the needs of behind-the-firewall, proprietary code repositories. At least Atlassian has free versions of its repository for FOSS and small-scale proprietary developers. Which is sort of nice."
Git (Score:5, Insightful)
"But isn't Git easy to install and use"
Yes, for certain users and environments.
In my experience, The folks who use Mercurial are more likely to be on Windows.
Mercurial tooling isn't as polished as the Subversion equivalents, but it's lightyears ahead of the Git tooling.
I'd be happy enough to pay for good Git tooling on Windows, but there doesn't appear to be a way to do so. Please correct me if I'm wrong.
Wow. (Score:5, Insightful)
I can't understand what the article summary is getting at. A reposting of a press release? An expression of /.'s parent company's interest in some organisation? Or a "tweet" accidentally posted as a /. article? A side effect of think-aloud sleep-typing?
Re:Wow. (Score:4, Insightful)
I'm also not sure what Roblimo's problem with Atlassian or proprietary software is; from my experience Atlassian produces fairly good software and charges far less than competitors.
Also, how about linking to the actual press release [atlassian.com] or a news story [techcrunch.com] that contains more than commentary?
Re:Wow. (Score:3, Insightful)
I can't understand what the article summary is getting at. A side effect of think-aloud sleep-typing?
I'd go with the sleep typing, but with the caveat that it's a brain-addled crack baby doing the sleep typing.
the majority of Atlassian's business comes from meeting the needs of behind-the-firewall, proprietary code repositories
That came straight out of Roblimo's crackpipe. So the majority of Atlassian's business comes from meeting the needs of proprietary code repositories? I didn't know that code repositories had needs, but I guess advanced ones like fanboy Roblimo's Git have gained sentience and are making demands, which Atlassian now makes the majority of its money from. By, uh... servicing the demands those repositories are making. Or... something.
Atlassian's cash cow has always been Jira, its bug tracker.
I think Roblimo's lost his marbles or something. The only point of this piece-o-shit article is to bash proprietary software and blow his FOSS horn out of his butthole like a Stallman-scented vuvuzela.
Re:Git (Score:1, Insightful)
Unfortunately, Mercurial gets one of the most important features of a DVCS horribly wrong. Not having cheap, fast, in-place branching is a deal breaker, and a mishmash of bookmarks, mq and other extensions isn't going to fix it.
Re:Git (Score:5, Insightful)
You're right.
Git does the job. But no, it isn't easy to use. It has an unintuitive set of commands, and various rudimentary, half-assed, poorly designed visual apps.
e.g.
git reset --soft HEAD^
WTF?
The proprietary Perforce dates from an earlier generation of SCM, and has a single code repository, rather than a distributed scheme. But it's commands and it's visual tool feel like they were actually designed. They are easy to learn, and need far less referring back to the manual. That's one of the reasons why people "feel better about proprietary software than FOSS".
Re:Git lacks tracking capabilities (Score:1, Insightful)
Yes and no.
What he is describing is not how push is used/intended in a true distributed environment, however, in a corporate setting, you don't have a true distributed environment. You will have a centralized repository, which everyone will be pushing to (it's the one that's backed up).
As Git was intended for a pure distributed environment, push *is* lacking in a centralized environment. It's perfect for pushing things from your private repository to *your* public repository (the one one the web server). In a centralized environment, you lack the information that Florian complains about.
On further thought, I think the problem comes from the concept of each repository having *one* owner. Anything pulled into my repository, or pushed into my public repository, will have been pulled/pushed there by me. Who actually wrote the code is tracked by Git, but I'm the one who pulled it into my repository. A centralized repository doesn't fit into that concept.
However, there are hooks (shell scripts) that run every time someone pushes to the repository. These could be set up to log which commit ids were pushed by whom, but this will be outside of Git.
Re:Git (Score:5, Insightful)
It has perfectly fine branching, see http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/ [stevelosh.com]
On another note, what kind of retarded wrote the summary? It makes no mention of who Atlassian or what Bitbucket are and instead spends time being an inflammatory git apology that doesn't even make any sense given that Mercurial is also opensource and free.
- a git/github and hg/bitbucket user
Re:Git (Score:1, Insightful)
git is a command-line tool. The "visual apps" are add-ons that aren't even part of git proper. Basically, the GUI stuff for git sucks because no one with any expertise in git thinks they are necessary. As for the commands being unintuitive, they seem no more or less intuitive than those of svn or hg. I can't comment on perforce. That's not to say that one can use git very well if you don't know what you are doing, just "figuring it out as you go" as one might try out a different web browser. But I didn't find git to be very hard to learn.
Re:Oh yeah, I had to google them (Score:1, Insightful)
Nah, he's just been in industry for decades. Companies like this rise and fall every few years. Once you've been developing software for decades, you lose track of how many different source control systems, bug trackers, planning tools and "collaboration suites" you've had to use.
It has only gotten worse with so many of these apps becoming web-based. They're ALL shittier than real applications, and they all look like the same pile of shit, too.
Last Straw (Score:4, Insightful)
That's it. I'm doing what others have done and blocking kdawson. This summary is crap and should never have been posted.
Horrible Summary (Score:2, Insightful)
Wow, is there a prize for worst summary ever?
"majority of Atlassian's business comes from ... proprietary code repositories
1. Atlassian doesn't have any products that are code repositories. It has one product that is a viewer for code repositories; Fisheye. It supports SSubversion, Perforce, CVS, CleareCase, Git and Mercurial.
2. I'm not privy to atlassian's financials, but I'm willing to bet that most of their money comes from Jira, with confluence a close second. Fisheye was an acquisition that they did a few years back when they bought Cenequa.
News for Nerds? More like Editorializing for Nerds.
Re:Git (Score:1, Insightful)
Once you go git you don't go back.
Re:Wow. (Score:5, Insightful)
No kidding. I am not one who usually comments on article submissions or the quality of the summary - I just ignore articles if I'm not interested in them - but this summary would (hopefully) be marked as troll if it was read as a comment. Given that something this rubbishy is posted by a /. editor, it's driving me to read /. less and less these days. Rationale - if this tripe is what makes it on to the front page, and from an editor, then my assurance of the quality of what's posted and what's left out is way down. What other value does /. have for me?
Re:Wow. (Score:2, Insightful)
Re:Git lacks tracking capabilities (Score:4, Insightful)
Most projects (even non-corporate ones) have a shared, centralized repository to which more than person can push, so the push attribution problem arises.
One reason for centralized repositories is that you cannot have decentralized deployment. Your organization has only got one www.example.org server (cluster), so eventually, there is a very strong constraint which linearizes development. Certain build and testing infrastructure also strongly favors linearity.
After the merge, it is a fast-forward push, and the server cannot distinguish it from new, legitimate development. The problem is not that Git doesn't prevent the push (after all, you need to be able to get new commits into the repository). The problem is that out of the box, Git does not keep track of who pushes what. Out of band solutions exist, and those hosters typically provide that.