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."
Code Repository? (Score:5, Informative)
Atlassian is a corporation, not a code repository.
Oh yeah, I had to google them (Score:3, Interesting)
I have seen their name inside a huge mess of java COTS which I was shovelling around as a part of a my day job. I doubt their main business is going to be operating bitbucket, more likely charging ten thousand bucks a seat for use of a copy of bitbucket inside corporate intranets, probably with some useless eclipse integration thrown in.
Re: (Score:1, Offtopic)
Goes to show you that kdawson + roblimo make an awesome combo.
Re: (Score:1)
...I doubt their main business is going to be operating bitbucket
Probably true
, more likely charging ten thousand bucks a seat for use of a copy of bitbucket inside corporate intranets
I can't speak of bitbucket, but we bought one of their flagship products (JIRA) at something like $100 per seat. Most of their products are very competitively priced, and usually free for open source projects.
, probably with some useless eclipse integration thrown in.
I find their Eclipse plugins to be of excellent quality and a massive productivity booster in our environment. All the devs in my team are using it.
Re: (Score:3, Informative)
Their wiki is pleasant to use and a snap to manage. All of their products are quite affordable to any corporation. Typically something like $8K will get you an unlimited user edition. Sometimes less, depends on which product.
C//
Horde of shit (Score:3, Interesting)
So all you need to do to get an article on the front page of Slashdot these days is a factually incorrect, barely coherent rambling shite of text, provided it bashes proprietary software and sings the praises of FOSS.
Slashdot: news for narrow minded, deluded nerds
Re: (Score:2)
Well, look at the submitter, who also authored TFA. The epitome of "factually incorrect, barely coherent"...
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.
Re: (Score:2)
I am a Mercurial user from way back, and my platforms of choice are OS X, BSD and Linux. Don't use Windows at all. But I would admit that it is somewhat easier for Windows users to get rolling with it than Git, or at least, it has been in the past.
Re: (Score:1)
The folks who use Mercurial are more likely to be on Windows.
Yep that's my experience as well--most likely cause being that Windows is a second class citizen when it comes to Git. Mercurial is Python based and less platform dependant.
Re: (Score:2, Funny)
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.
What are you talking about? msysgit [google.com] is dead simple to install, and provides you with a perfectly functional Bash shell.
Yeah, I've been wondering how to increase the usability further, by using zsh instead of Bash, but this is not really a pressing issue since Bash is pretty awesome too.
Re: (Score:2)
provides you with a perfectly functional Bash shell
There-in lies a problem. While I'd be perfectly happy to consider using Git there is no way I could recommend it in my workplace until such time as there are good "tools from noddies" like TortoiseSVN and VisualSVN. We don't really need a full DVCS, so we are not really Git's target audience, I'd guess there are many companies out there that could take advantage of a DVCS that won't consider Git for similar reasons.
Re: (Score:2)
Here http://code.google.com/p/tortoisegit/ [google.com]
Now shut up and happily consider git.
Re: (Score:2)
Want want want....
Re: (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: (Score:2)
tell me more. My company is thinking of moving to Mercurial, and whilst I think its a fine tool, I'm a little concerned it wouldn't quite suitable for us (we have large repositories).
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: (Score:2)
No, no he's not. http://slashdot.org/faq/slashmeta.shtml#sm100 [slashdot.org]
Re: (Score:2)
Re: (Score:2)
Your company should have a real need for a DSCM, otherwise, Mercurial or Git have little value.
Merging/branching can be a little easier in Git vs. Svn. I've used it before on a team and have seen some things become easier; we had a dev working offsite with no access to our repo and we would just email back and forth the code dir every week and at the end of each week, merge in all his changes. However, this was more of a policy 'issue' on our end as I would have preferred not to merge his stuff in in the fi
Re: (Score:2)
Yes, I think that's the main issue - DVCS are 'cool' so lots fo devs want to use them, and then start making reasons why they are so fantastic, which pulls other devs in, and eventually management hears about it and starts believing the hyped up bits. Mercurial was positioned as a perfect solution to rolling changes to multiple branches. (when I think the problem is a human one, SVN is perfectly good for merging, until things get complicated and then all VCSs are complicated).
We have a 12Gig SVN repo so tha
Re: (Score:2)
I think youre missing on a lot of values a DSCM can bring you.
Some of my clients use svn, I use git svn bridge. Some of the things I can do:
* have one directory extract locally
* full local history
* stash / pop when a quick fix request comes in
* local branches (I used to have multiple checkouts laying around with svn...) Particularly useful when working disconnected (travelling, or on site without access to companys network). And that helps me make multiple commits, which makes my commits easily reviewable.
Re: (Score:2)
thing is, those things aren't so great.
1 directory extract locally... my SVN repo is 12Gb. That's a lot of network traffic and disc space for a lot of stuff I do not need to see of manage. When we migrate the core product, that'll be even larger. I suppose the git solution would be to have many repositories.. but then you'er losing the benefit you've claimed.
full local history: fair enough, but its not that big a deal, on the relatively few occasions I want history (that isn't just the previous version), a
Re: (Score:2)
> 1 directory extract locally... my SVN repo is 12Gb. [..]
I meant one extract instead of multiple checkouts. When I was working with subversion, I always had to play with multiple checkouts when working on several things at a time (not nice, but sometimes you're forced to). With SVN, no ability to stash the changes, need to be online to make a checkout or new branch, etc. And it's slow!
> That's a lot of network traffic and disc space for a lot of stuff I do not need to see of manage.
For the do not see
I went cvs - svn - git -hg (Score:2)
I tried out git first, and used it in a real project. I really wanted to like it, but after having to go back to the documentation for the umpteenth time to figure out how to do something that should be dead easy, I decided to give Mercurial a try. I haven't looked back since. The commmand set is wonderfully logical, once you wrap your head around the whole DVCS and changeset concept, as opposed to working with revisions. Everything works as you would expect, and if not, is easy to look up the command in qu
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: (Score:3, Informative)
You should give Mercurial [selenic.com] a try. The thing that got me to use it in 2005, when it was pre-1.0, was how clean and obvious the command line interface was. I don't generally use graphical tools for development work, so I can't gauge the various GUIs available for it, but I do know that a lot of people like TortoiseHG [bitbucket.org].
I've used Perforce as well, and it has its strange quirks and complexities too, though I agree that git's command line interface leaves a great deal to be desired in comparison. I think Mercuri
Re: (Score:2)
So, given these two commands:
git reset --soft HEAD^
hg rollback
which one do you think is more intuitive and immediately apparent to the user?
And even more important, which one is easier to find in the documentation?
Things like these are why I ditched git in favor of Mercurial.
Re: (Score:2)
So, given these two commands:
git reset --soft HEAD^
hg rollback
which one do you think is more intuitive and immediately apparent to the user?
Unless I'm confused, those don't do the same thing. From what I can tell, "hg rollback" is used:
"to revert changes that have been commited to the local repository but not been pushed to another repository yet. You can only rollback the last hg command."
"git reset" doesn't do that. "git reset --soft revnum" move the HEAD of the repository to a given position *without c
Re: (Score:2)
hg rollback doesn't touch other changes in your working copy. But you're right about being able to undo only one commit.
Re: (Score:2)
hg rollback doesn't touch other changes in your working copy.
Err, I think you still misunderstand what "git reset --soft" does.
Let's say you had these commits, which changed the corresponding files:
3 - X.txt
2 - Y.txt
1 - Z.txt
And your working copy was *clean*. Now, suppose you did this:
git reset --soft 1
If you did a "git status", it would show X.txt and Y.txt as *modified* and in your index. And if you did a "git diff --cached", you'd see the changes in commit 2 and 3. You could then do a "git commit", an
Re: (Score:2)
hg rollback will show the affected files as modified in your working directory. You can commit again straight from this point.It's one of the most frequent reasons why I use it: i commit, then realize that I forgot a modification or have to add one more file. hg rollback will let me do that.
I won't let me merge multiple past commits, though.
Re: (Score:2)
I think this demonstrates my point about git being unintuitive. Even after having been given an explanation, it's still hard to understand.
Re: (Score:2)
Yeah, you're right, we should do away with any powerful software features that people might find a little difficult to understand initially... God forbid powerful tools should require a little thought to learn and use.
Re: (Score:2)
It's not complex because it's pwoereful. It's accidental complexity. There's no reason why a SCM with the necessary features of git can't have an easy to understand set of commands.
It's this kind of shit - believing that accidental complexity is OK - that accounts for the reason why the open source software scene hasn't taken over from commercial software, even though it has huge advantage of usually being no cost. Most people would rather pay for something that's easy to learn and easy to use.
Re: (Score:2)
Those features of git are possible to do in other source control systems (like Mercurial) without the bizarre syntax that means nothing to the uninitiated and is even difficult to explain to someone who wants to understand.
I really dislike working with git because it is strange, confusing and makes no sense. And that's not just a matter of being very familiar with the Mercurial command syntax. I know how hash DAG based DVCS systems work, and git still makes no sense.
Re: (Score:2)
Those features of git are possible to do in other source control systems (like Mercurial) without the bizarre syntax that means nothing to the uninitiated and is even difficult to explain to someone who wants to understand
It is? Okay, so, just ooc (seriously, I am just curious), how do you do the equivalent of "git reset --soft HEAD~5" in hg? "hg rollback" only goes one commit up, so clearly that ain't it.
I know how hash DAG based DVCS systems work, and git still makes no sense.
Well, no offense, but it so
Re: (Score:2)
It is? Okay, so, just ooc (seriously, I am just curious), how do you do the equivalent of "git reset --soft HEAD~5" in hg? "hg rollback" only goes one commit up, so clearly that ain't it.
First, a few questions:
If I have the answers to those questions, I can tell you which Mercurial command (or short series of commands) does it, though if your answer to the last one is particularly interesting, it may be kind of complicated.
Well, no offense, but it sounds like you're just not trying that hard. Git's terminology is slightly odd (the term 'index', referring to the staging area, is a certainly strange), but fundamentally, it's operations are just operations on the commit tree. There's nothing really that confusing going on there, save that some of git's commands allow for some fairly low-level manipulation of said tree.
That's true, but, for example, the 'reset' command suggests absolutely nothing to me. W
Re: (Score:2)
No. Not explicitly. The state of the tree would be changed to reflect a past commit. The commits after that commit are still in the history.
If a new commit is done from that past point, the tree sprouts a branch and HEAD becomes assigned to it. Still, the old "abandoned" branch of the history is not deleted. It might however be garbage collected at some point, if no branch name is explicitly assigned to any of the commits in it, since they'd
Re: (Score:2)
The other commentor did a good job covering your other questions, so I won't bother with them.
That's true, but, for example, the 'reset' command suggests absolutely nothing to me. Why isn't it named 'rollback' or 'undo' or 'revert' or something else vaguely related to revisions and transactions?
Because none of those terms is accurate. What "git reset" does is move the HEAD of the current branch somewhere, and optionally affect the index and the working copy. "Rollback", "undo", and "revert" all describe a
Re: (Score:2)
It's not complex because it's pwoereful.
No, it's complex because it's powerful. "git reset" is far more flexible than "hg rollback", and using it forces the user to understand what's going on when git manages the tree, because it allows the user to perform interesting, low-level manipulations of the repository.
If you can't handle that, that's fine, use another tool. But "git reset", for example, exists, and is named the way it is, for a very good reason. This isn't "accidental complexity". This is "com
Re: (Score:2)
"Forces the user to understand?" Sounds rather fascist. And also unrealistic. In reality it'll be wielded by many people who don't understand, and will thus make mistakes, and possibly lose data.
No, the complexity is accidental. Using the example you give:
"hg rollback" may only
Re: (Score:2)
"hg rollback" may only go back one level, but it does have the great advantage of actually being named after what it does.
And it's limited as a consequence. You've illustrated my exact point for me: the tool can be powerful, or it can be simple. Take your pick.
Reset implies going back to the beginning, not going back one or more steps.
Sure, if you stop reading at "git reset". "git reset <revspec>" should make it clear something more than that is going on. But I know, you don't want to have to, l
Re: (Score:2)
Python's not bad. Haven't used it in a few years though. Where did that come from? Because I praised the fact that Mercurial has commands named after what they do? If so the logic breaks down because I've never used Mercurial.
If it's because Python is very productive, because it's easy to understand AND powerful, guilty as charged. If we're following that line of reasoning, perhaps your tastes lie more along the lines of perl. Does the job, but it's unneces
Re: (Score:2)
If it's because Python is very productive, because it's easy to understand AND powerful, guilty as charged.
No, it's because Guido has decided precisely how you should be coding. *He* decided how the code should be indented and laid out. He decided there should only be a single, Guido-approved way of doing anything.
My point is that someone who says "you should never touch the repo!" clearly likes rigid boundaries that can't be crossed, and Python would, I'm sure, be very appealing to a person like that.
Me,
Re: (Score:2)
Ah, the paradox of choice. The incorrect assumption that more choice is necessarily a good thing. It isn't.
Take C-like languages. Block beginning and end defined with braces. Whitespace almost completely optional. So, some people put the opening brace at the end of the proceeding line. Some people on
Re: (Score:2)
That's what they say about learning French.
Git is a piece of software with the simple objective of keeping a history of changes, and sharing them with others. It shouldn't be like learning a foreign language. The commands should be intuitive, not a hard won skill set, which you need to use often to keep in your head.
Re: (Score:2)
Oh, so git reset --soft HEAD^ is like hg debugsetparents, which sets what changeset(s) Mercurial considers the working directory to be a branch off of.
And git reset --hard HEAD^ is like hg update -C <revnum> .
Re: (Score:2)
Not exactly. I mean, assuming you understand those git commands well (I can't tell not familiar with Mercurial), you may have found some equivalent hg commands.
But that's not the point.
The point is that the git command is extremely flexible. It has 3 components (reset; --soft vs --hard [and there's more reset methods, not just those two]; and the HEAD^ which is a "treeish", a way to specify history position, one out of many). Those components can be combined in a lot of ways. Furthermore, some of them are r
Re: (Score:2)
And yet none of the words that you've used to explain it appear in the command (nor abbreviations nor synonyms.) There's nothing in that command that makes it look like it means what you say it does. Your explanaion is right (I think), the fault lies with the way git commands were designed. Or rather not designed.
Git is a distributed system, as opposed to a single code repository. In that way it's more powerful than Per
Re: (Score:2)
Re-writing history isn't exactly bad. In a DVCS system, you have a local repository that nobody else has seen yet. You commit things to this early and often, frequently things that make no sense to anyone else. And this is because nobody can see them.
Re-writing history is often a very nice thing to do before you publish your changes to a wider audience.
In systems like Perforce, you often work on a change for days before actually committing it because once you commit it, it's in the big centralized reposi
Re: (Score:2)
And you should be keeping all that history for yourself to look at if needs be. If you screw up and need to go back to something from an hour ago, or a day ago, then it should still be there. history should not be rewritten so that those versions have disappear
Re: (Score:2)
I'm not misunderstanding. I'm pointing out where git allows a hack to "change history" that should not be there, and it's existence adds extra complexity and opportunities to shoot yourself in the foot. It should not be like that.
Well, Mercurial makes it a lot hard to change history than git does. But it's still possible.
And no Perforce shop I've ever seen has ever had a private branch for each developer. You could work that way, it's true, but I've never seen it done.
Re: (Score:2)
The perforce shops that I've worked at all had private branches for developers. It's not unusual.
http://www.google.co.uk/search?hl=en&safe=off&client=safari&rls=en&q=perforce+private+branch&aq=f&aqi=g1&aql=&oq=&gs_rfai= [google.co.uk]
Given that it gives what you want, without the need for rewriting history, I'd say the Perforce shops you have seen have missed a useful trick.
Re: (Score:2)
It still doesn't give me what I want, because I want to be able to commit on my laptop when I have no Internet connection of any kind. But yes, it comes closer.
I also feel the Perforce's tracking of merges is somewhat lacking and a bit confusing in comparison with how they're tracked in a DVCS. But it's certainly a whole ton better than either CVS or Subversion.
Re: (Score:2)
The equivalent in Mercurial is `hg rollback`. ;-)
Re: (Score:2)
Have you heard the phrase "Damning with faint praise"?
No doubt git is better than svn, just as bash is better than command.com. But that ain't saying much.
Re: (Score:2)
FTFY
Re: (Score:2)
Crackmonkey.
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: (Score:2)
A side effect of think-aloud sleep-typing?
Nah, think-aloud sleep typing is more like
I, on the other hand, have found it quite impossible to predict orange growths with the kabbalah. Can you explain your methods and how I might improve mine?
Re: (Score:3, Funny)
That makes a hell of a lot more sense than the article summary.
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: (Score:2)
I've been less than pleased with the kwality of Atlassian software, namely Confluence & JIRA. Neither seems to be able to stay up much longer than 24 hours before consuming a lot of resources and refusing to respond. It's gotten to the point where, for stability's sake, I have cronjobs stop them, then kill -9 any leftover java processes, then start them. Every. Night. There are some other problems I have with them, too, but this isn't necessarily the place to air those.
I agree with you on the submitter'
Re: (Score:2)
Ahahahahahahahahahahahaha! You are joking, right?
Confluence is classic enterprise software. Purchased by people who never have to use it. I've used it and it is unintuitive shit. They've taken what should be a fundamentally simple piece of software - a wiki - and made it into the bastard lovechild of Lotus Notes and Outlook so t
Re: (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 repositorie
Re: (Score:2)
Ah, I get it - I finally clicked on the first link, which goes straight to...an article written by one Mr. Roblimo. That article has a few [atlassian.com] more links (actually, apart from that one, the only other links are to Atlassian and Bitbucket). If I were a cynical type of chap, I'd suggest he's trying to pump up traffic to his page on this website and being too lazy to do it well.
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: (Score:2, Insightful)
Why does the fact Git is free matter here? (Score:5, Informative)
Mercurial [selenic.com] is just as free, and just as easy to set up. Code hosting repositories are about someone else managing your connectivity, storage and backups for you, not about them building DVCS software for you.
Re: (Score:3, Interesting)
Yes.... and until there's a cheap hosting provider that offers WebDAV, Bitbucket is a good option. However, if you're an enterprise, such as a bank, you might be concerned about the risk of your code repository site getting hacked.... in that regard, Open Source projects are more amenable to services like this... at least until DVCS clients support host-proof encryption of files on the server.
OTOH they can offer web-based tools that make it easy to visualize changes and other things that would be a
Atlassian has some nice stuff (Score:2)
I'd rather use the open source product every time but I have to admit Atlassian has some nice feature rich developer and development management tools.
JIRA's just so so and Confluence just plain sucks due to horrible Rich Text editing that destroys formatting and awful proprietary markup. (I have to use it every day. It's usable for quick notes. Anything bigger or with pics goes into a Word doc). However some of the JIRA plugins and especially their FIsheye product is awesome for code analysis and comparison
Re: (Score:2)
Lord do I ever feel your pain.
For project management, JIRA isn't half bad with a little tweaking (we have an excel doc plugged into it which graphs our sprint progress) but Confluence is utter crap. For a standard wiki, I suppose it's passable, but here we use it for our requirement management (unfortunately), maintaining traceability between reqs/tests is a nightmare...
I agree about Fisheye, it's the bee's knees.
Re: (Score:2)
Before being a jackass, why don't you read the product's specs:
Requirements Gathering
A requirements specification is never complete. It is an iterative document showing only a team's intentions at a given point in time. Confluence gives development teams the flexibility to rapidly update specs and keep everyone updated as requirements change.
http://www.atlassian.com/software/confluence/tour/documentation-software.jsp [atlassian.com]
It was made for requirements, amongst other things. I didn't have the luxury of picking the tool and besides, except for Doors, I found no requirement management tool which answers all of our requirements neatly.
Re: (Score:2)
Uh-huh...
Hahahahahaha! Nice troll.
Re: (Score:2)
How old are you? 3?
Git lacks tracking capabilities (Score:2, Interesting)
Developers can push arbitrary data and metadata into the repository. The standard server does not map branch updates to user accounts. Here's an example: Suppose developer A merges the master branch into a development branch (which is not ready for merging into the master). Git will record a merge commit, attributed to developer A. Developer B then accidentally pushes the development branch onto the master. This is now a fast-forward merge, so no additional commit will be created, and the mistake is not at
Re: (Score:1, Informative)
Then why do it? He should clone the master branch and work with that. Branching in git is a non-issue, it's that cheap.
Which development branch? B's? You do realise that since git is distributed, A's and B's and the master upstream repositories are three completely distinct repositories.
Furthermore, there's a disti
Re: (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
Re: (Score:2)
We use indefero with git. Basically we setup a project on the server. Each user has an account on indefero with their ssh key uploaded to it.
Then pull from there, do their work and push back when they are done. Works great and even allows nice workflows like this.
I have an intern, he checkouts from the server with read only permissions. He does his work and notifies me that he is done. I then pull from the server and do a checkout from him, validate his code and push it it to origin if it meets our standard
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.
Re: (Score:2)
Yes, it does, what on Earth are you talking about? In Git, each changeset has an author AND a commiter, and they can be different persons. There's a clear distinction between which developer created the changeset originally and who's moving it around the repository, or to other repositories.
I don't see why a centralized repository is a problem, as long as you set the identities of the developers on the machine hosting the reposit
That submission is just plain wrong (Score:1)
"the majority of Atlassian's business comes from meeting the needs of behind-the-firewall, proprietary code repositories"
Eh. Most products developed inhouse are hosted like that. No problem with that. Not every business want to do the "cloud-thing", but that could be illegal now?
And code repositories, most businesses uses svn, git or cvs, all of them are open source from what I know.
Has the cloud-hype been so successfull that people think that FOSS must be something in the cloud now?
Re: (Score:2)
And code repositories, most businesses uses svn, git or cvs, all of them are open source from what I know.
I regret to tell you that where I work we're forced to use MKS. But the development centers that know what version control is for end up using something else for the day-to-day work (like SVN) then exporting it off to MKS when the work is done, just to conform to Corporate rules.
kdawson, master of useless summaries (Score:5, Interesting)
Atlassian makes code tracking and corporate-friendly wiki products. They're pretty nice, actually. It's pretty easy to write plugins that add flexible functionality to their products. I was and am a pretty big fan of Jira and Confluence, and they're pretty responsive to their customers. Their products are (last I checked) pretty reasonably priced, and integrate into Subversion, CVS, and other source control products pretty easily - including Git.
Last I checked, Git didn't really lend itself to project issue tracking - which is what Jira does. So if you must bitch about non-free Jira, you could at least make an *intelligent* article comparison to a open-source issue-tracker like Trac (another excellent product).
Alas, we're unlikely to see any intelligent comparisons from kdawson. The "lazy-shrug" dept is all too relevant here, but not for the reasons kdawson used it.
Re: (Score:2, Interesting)
Also: way to change the article summary without an "Edit" notation, guys. That's awesome work, /. The summary is still incoherent.
Don't forget github.com (Score:2, Informative)
You are remiss in not mentioning github.com [github.com] which does the favor of free, immediate online hosting of OSS projects and content under git. I don't know how many presenters I've seen with their slides and demo code all on github. It's the killer app that makes git really rock.
Wow. So many errors in such a short summary. (Score:1)
FAIL (Score:1, Redundant)
Wow. That summary was amazingly bad. You fail the Internets, sir.
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.
Re: (Score:2)
I hadn't even realised that was possible. Thank You.
OT: Isn't Atlassian Confluence a POS? (Score:2)
I have to use it at work and it's a pain in the ass. The markup language is horrible, but it's a question of taste I guess. However some basic functions are missing; I couldn't find a way to list another user's contributions for instance. The ACL management is a pain in the ass. It lacks user-generated templates. The UI is rather bad.
Is there a good reason to pay that much money for such bad software?
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
Give me a break (Score:2)
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.
Give me a break. When I was looking for a repo for ObjectCloud [objectcloud.com], I listened to a one-hour video of Linus rambling about how wonderful Git and distributed SCM are. I tried Git for about two days until I got stuck in a situation where I realized I'd have to spend at least an hour "problem solving" by crawling lots of well-meaning, but difficult-to-read, forum posts. I've never had such a confusing experience with an SCM before in my life.
At that moment I switched to Mercurial. It works, and it's easier to
Re: (Score:2)
Git is MacGyver, Mercurial is James Bond [wordpress.com]. Use the one that fits your work style and requirements. The right tool at the right time.
Re: (Score:2)
That article is 100% on the mark when it talks about Mercurial's forking problems. I've been bitten by that issue, but it wasn't until after I became comfortable with the tool and knew that I could still get my data out.
Perhaps my original post came off too much as being yet another Mercurial vs. git post; which wasn't my intention. What I was replying to is the sort of "xxx MUST be better because it's 100% open source" attitude. Even though I like the concepts behind open source, I find the "it's better
Re: (Score:1)
I realize it's a bit tinfoil-y, but really, what other explanation is their for this postings content?
Head injury?
Everyone has a breaking point. For me and slashdot, it's this "article". I would vote it simply be removed and forgotten about.
Re: (Score:2)
A couple of years ago we (Atlassian) showed up at a trade show with a "Friends don't let friends use Sourceforge" banner. Maybe there's some latent corporate hostility. :)
Regardless, I don't understand what this article is truing to say and I sit two desks across from the Bitbucket team!
Re: (Score:2)
Thanks for this even-handed analysis, borne out of your long years of experience in the industry. It is clear that your vision and insight is hard-earned, and that you're not just parroting the standard slashdot groupthink in a karma whoring of immense proportions.
Let's ask your prof if YOU understand software.
Re: (Score:2)
So you're saying that the feature set of a product is more important than how it was developed?
Color me shocked.