3 ms·
- You get exposure to big expensive technology you might not otherwise get to play with at a cash strapped startup
by mindstab 13y ago
- You get exposure to big expensive technology you might not otherwise get to play with at a cash strapped startup
- InclinedPlane 13y agoSort of, there's an evil flip-side to that. Often you end up burdened with expensive corporate-friendly technology as well as "official internal tools" which are in every way vastly inferior to open source stuff but you have to use them because that's what the company has chosen to use. A great example in this vein is sharepoint. Other examples might be, say, team foundation as source control versus git, or IIS vs nginx, etc.
- iyulaev 13y ago"team foundation as source control versus git" How much experience do you have with TFS? It's a different animal than Git, but my TFS-using colleagues really, really like it.
- deleted 13y ago[deleted]
- sirmarksalot 13y agoMy experience is limited, but the source control aspect of TFS seems really crude compared to git. Branching is about as hard as an old-school Perforce or CVS repository, but without the flexibility in managing your local changes that those systems allow. It only lets you keep one changeset active at a time, which can be hacked around using shelvesets, but not without occasional hiccups (TF Power Tools are often the only way to recover your work after particular kinds of operations). I've found that every workflow I can come up with is "wrong" in some way, but none of the documentation tells me what the "right" way is. Git may have been in a similar place when it was first released, but nowadays there are plenty of good tutorials that walk you through the way to think about it. The GUI is clunky and requires lots of clicks to perform routine tasks. For example, to view a file's history, you need to open each changeset individually and diff the file in each one. The command line is no better, and makes heavy use of the "observe something to initialize it" anti-pattern. The main draw seems to be its integration with issue tracking, unit tests, code reviews and project management. It's trying to be a one-stop shop for everything, but the problem is that each feature has a better stand-alone equivalent. So you either lose the synergy of having one tool for everything, or you sacrifice the features that you really want from your favorite source repository, code review tool, diff utility and bug trackers. This has become quite a rant, but I'd really like to hear a good explanation for some of these things, or at least somebody to tell me what I'm doing wrong. The worst is when somebody knowingly says "come on, it's not that bad" without actually offering a more functional workflow.
- InclinedPlane 13y agoRealistically I'd have to consider myself pretty close to an expert in TFS, although I'm sure there's a ton I don't know about it. Overall, TFS, as a source control system, is pretty decent, definitely in the top few of the best source control systems out there. However, it has a lot of downsides. It's a serious pain to administrate, and an even bigger pain to initially set up. It has a huge number of "quirks" that are really just misfeatures or defects for most users. For example, binary files are exclusive checkout by default (meaning only one workspace can have a specific binary file editable at any given time) which seems like a good idea naively but tends to bite you in the ass almost always in any real-world example. And most TF admins aren't smart enough to know how to change the setting for it, as far as I've seen anyway. Also, access control is like pulling teeth, you'd think it should be easy-peasy given that it's all GUI based and what-not but it's crazy. Similarly, things like triggers can work in completely non-intuitive ways that are really easy for, say, a moderately trained dev who's trying to be a part-time admin to screw up in ways that impact a huge amount of people very quickly (which I've seen happen routinely). There are some nifty features, like shelvesets, and it supports a reasonable branching model with a reasonably decent merging system, though if you use it long enough you'll probably eventually run into one or another nightmare scenario that takes a long time to figure out. For most projects I wouldn't recommend it over, say, git + github/gitlab or other free source control options. The one advantage that TFS has is that it's far more capable of handling extremely large code bases (e.g. hundreds of gigabytes of data, millions of files) as long as it's configured well, whereas git will pretty much just choke. Also, the Visual Studio integration of TFS is pretty good, so if you use that as your primary IDE TFS will have a moderate advantage in ease of use. Of course all of this scales to how skilled you are with using source control at a low level anyway. If you're a dev who has zero interest in learning anything more than "checkout/checkin" and you hope that merges and branching and whatnot are handled by people who are not you then TFS is pretty much right at your level, it's definitely super easy to use for those common cases.
- lucasjans 13y agoWhat's a better, free open source alternative to SharePoint? I don't disagree with the point but I would be surprised (and interested) if there was a open source alternative that compared to SharePoint.
- nsomaru 13y agoHave a look at Alfresco. Also, see my question to parent.
- nsomaru 13y agoAs an aside, what is the 'vastly superior' FOSS alternative to Sharepoint? I've looked at Alfresco, but it was a pain to install and configure. Also, it doesn't seem to be 'true' FOSS because we get access to dirty HEAD code and not the code they use for the 'enterprise' version. They further refuse to commit the name 'stable' to any of the community versions.