|
Out of curiousity: Are any of you SVN/git guys going to be taking a look at TFS express?
|
#
¿
Feb 28, 2012 20:49
|
|
|
|
| # ¿ May 14, 2024 22:26 |
|
|
wwb posted:I'm a pretty dyed in the wool MS guy and I won't use sharepoint or TFS because the products blow that much. I don't know enough about Sharepoint to debate the point, but why do you think that TFS blows? My employer does TFS consulting and I'm currently writing a bunch of cool software leveraging the TFS API, so I'm curious to know what soured you on it.
|
|
#
¿
Feb 28, 2012 21:52
|
|
|
wwb posted:Locked checkouts. You can explicitly lock a file, but I've never seen a good reason to do so. It defaults to no locks, at least in 2010. quote:Needing $8k + worth of licensing to work beyond TFS. TFS can be pricey, I'll give you that. That's why Microsoft is releasing an Express edition; they want to upsell. quote:Sharepoint integration. Sharepoint isn't required to use TFS. If you're going to ding it because it can integrate with Sharepoint, I don't know what to tell you. quote:Requiring Visual Studio on my build server. Not true, as far as I know. I could be wrong on this one, though. quote:But it is managerware more than useful development tool. I've only used VSS and TFS (2008, 2010, and the beta of version 11) professionally, so I can't speak to the strengths and weaknesses of TFS over anything other than VSS. I'd disagree with that statement, though. With a minimum amount of dicking around, you can have source control and CI scripts running. If anything, I've seen the "managerware" aspects of it misused/underused/unused more than the source control aspect.
|
|
#
¿
Feb 29, 2012 00:23
|
|
|
Team Foundation Server 2012 Express is out, in case anyone was interested in trying it out. I know TFS doesn't get a lot of love in this thread, but I figure it's worth mentioning. Express supports up to 5 developers.
|
|
#
¿
Aug 21, 2012 16:08
|
|
|
uXs posted:Is VS2012 really out yet? Or is it only people with expensive MSDN subscriptions or whatever. Express editions are out. MSDN subscribers can get the full thing. Everyone else gets it in a few weeks.
|
|
#
¿
Aug 21, 2012 17:31
|
|
|
I'm working on some CI stuff for a client using TFS. They necessarily have very large solutions with lots of dependencies, so we made the decision to do binary references instead of having solutions with hundreds of project references, with CI builds set up to automatically update the binaries on build, and then rebuild any projects using those binaries. I just finished mapping out what-triggers-what, and there's one massive solution that's used by basically every other project. It triggers 65 additional builds. One particular build ends up being run 18 times.  Running all 66 builds would probably take 3-4 hours, thus entirely defeating the purpose of CI. I don't have any questions, I just wanted to vent.
|
|
#
¿
Sep 24, 2012 21:43
|
|
|
Gazpacho posted:When I've used CVS or Perforce or TFS in a team project, that has always been accompanied by pressure to submit only fully-functional, fully-tested changes to the repository. That's more a symptom of poor branching practices than anything else. I always encourage development to take place in a dev branch, where the only barrier to checkin should be that the code compiles. It's only as you push the code back down towards the trunk (through any other intermediate branches) that things like CI come into play.
|
|
#
¿
Jul 8, 2013 17:54
|
|
|
JawnV6 posted:Under 30, no family, still a bright eyed idealist. I still code for fun all the time. I'm 31, have a girlfriend that lives with me (no kids though), and I'm as jaded and bitter as they come. I don't contribute to github though, do I still count?
|
|
#
¿
Jul 17, 2013 20:53
|
|
|
Zhentar posted:People who think programming is fun tend to be more interested in solving interesting programming problems than boring business problems. So they usually come up with ways to turn boring business problems into interesting programming problems. This can turn out well, but it can also be a pretty bad thing. It's usually a bad thing. You end up with the inner platform effect, because writing some code to serialize/deserialize XML documents is so boring. It's way more interesting to write a database-driven XML generation engine. Then you can make any XML document in the world, as long as you spend 3 weeks carefully inserting the correct rows, and you don't mind waiting 3 hours for it to generate a 100K XML file. (If you can't tell, I'm really bitter about having to support that XML engine. I complain about it every chance I get)
|
|
#
¿
Jul 18, 2013 00:09
|
|
|
There's so much TFS hate in this thread. Using the cloud-hosted TFS Service with Git is a great idea. TFS has really rich, powerful project management tools. For the record, I've had clients who use TFS for Java applications before, and they loved it.
|
|
#
¿
Jul 26, 2013 12:48
|
|
|
wwb posted:I admit the modern version is certainly markedly better than what came before and that the current iteration might even be a viable SCM platform, I have still yet to see anyone who isn't: I liked it before I consulted in it. Developers usually don't have much to say about it because when it's working properly, it's pretty unobtrusive, just like any good source control should be. It has great tools for project management/reporting, which is why group C likes it. [edit] And it's definitely been a viable source control platform for a long time. I started using TFS2008 in 2009 or so. I can't speak to VSTS2005, that seems like it was a clusterfuck. New Yorp New Yorp fucked around with this message at 18:32 on Jul 26, 2013 |
|
#
¿
Jul 26, 2013 18:29
|
|
|
hieronymus posted:TFS is good at some things, but it completely defeats the point if you're working in Java. The cool parts about TFS like the msbuild integration, Visual Studio integration, etc all are not going to work with a Java toolset. If he were doing like a C# app and he was tooled using visual studio, it wouldn't be such a bad idea. There's an Eclipse plugin for TFS that gives similar IDE integration. Build is a bit trickier, there are resources to get it working. I'm not saying that TFS is the best choice for source control for Java applications, but Microsoft is aggressively pushing it out into the non-Microsoft dev world (see: Git fully integrated in TFS2013). It's a viable choice, especially in this case.
|
|
#
¿
Jul 26, 2013 20:37
|
|
|
Hello my TFS-hating or TFS-ambivalent friends! Brian Keller at Microsoft just released a VS/TFS2013 ALM VM. I'm playing with the native Git support right now and what I'm seeing is definitely encouraging. If you're a .NET shop and you've decided not to use TFS because you don't like CVCS, take a look at TFS2013. The Git tools are pretty rad, and it works flawlessly with build and deployment (with InRelease).
|
|
#
¿
Aug 3, 2013 01:35
|
|
|
I've been tasked with giving a presentation on integrating Eclipse with Git + TFS, so I have a few Git questions for people that have a ton more experience actually using Git day-to-day; my experience with Git is limited to Github. The "Eclipse" part is basically irrelevant to my questions; I set up EGit and my demo is basically going to be source controlling "hello world" in Java; the focus isn't on the language, but on Git and the IDE. EGit is pretty straightforward so no worries there. So, I intend to demo two ways of using Git + TFS:
Given that with TFS2012, the first step is to "clone" the TFS source tree into a local repo (and then use that local repo to sync back and forth to TFS), what's the best practice regarding that? Should I clone my local repo again and treat the TFS-syncing repo as a "remote" repository, or just develop directly against that repo? Also, what's the generally accepted practice regarding branching? I know Git is branch-happy because it's cheap, but is it frowned upon to clone a repo and then commit changes directly? When should I merge versus rebase? I'm not super clear on that, although I've admittedly not done a lot of reading on rebasing.
|
|
#
¿
Aug 7, 2013 03:58
|
|
|
Dirty Frank posted:There's been a bit of talk about TFS and Git so maybe someone can give me some pointers here. Option #1: Upgrade to VS2012 and use local workspaces. That will download a local copy of the TFS repo. It's not DVCS, but it should solve the problem you're having. It'll only communicate with the server for synchronization operations, conflict detection/resolution and checkins. Option #2: Use GIT-TF. Git-tf will pull down TFS source code to a local git repo. You commit to your local repo, then use git-tf checkin and it goes and sticks the changes into TFS.
|
|
#
¿
Aug 20, 2013 17:18
|
|
|
Essential posted:Recently I created a Team Foundation Service account so I can have offsite backups and work from my laptop or desktop without copying files via usb (and to just have a better tool for source control). I realized today though I may have set my projects up incorrectly. Instead of creating a folder for the solution on tfs, I pushed the solutions directly into the tfs workspace. Should I have created a solution folder and put my projects there instead? Also, this is specific to visual studio, but should I be including the 'packages' folder in tfs, or let that resolve via nuget on each local machine? Yes, that's wrong. Ideally, you'd have a "Main" folder with folders for all of your solutions beneath that. Then you can branch "Main" if you want to do development work in a separate dev branch. As for NuGet, I'm a fan of source controlling my third-party dependencies. That way, all anyone working on your code has to do is pull down what's in TFS, and it all builds and works like magic. Essential posted:May as well ask this too: Should a VS Solution be it's own project in tfs, or should each VS Project be it's own project in tfs? Assuming a solution had a UI project, DAL project and business layer project what's the right way to set that up in tfs? Under 1 tfs project or multiple tfs projects? You only need one team project. If you had two teams of developers working on completely separate applications with no dependencies, then you'd have two team projects.
|
|
#
¿
Sep 5, 2013 00:53
|
|
|
Essential posted:Thanks Ithaqua! One clarification though. I am a single developer so I AM the team. Let's say I am building a web application for Company A and I am building a desktop application for Company B (2 completely seperate apps with no dependencies). Would I have 2 team projects in tfs or just 1 and have both solutions under the "Main" folder? I forget if TF Service has a limit on the number of team projects you can use. My gut instinct would be to have one TP per client, although having 30 team projects for 30 simple websites is probably overkill. One argument for keeping each client's code in its own team project would be if you wanted to give them access down the line so the client can review the product backlog and the progress of the current sprint.
|
|
#
¿
Sep 5, 2013 16:50
|
|
|
Essential posted:Yeah good question. I assume since you want each project to have it's own backlog, sprints, etc. you would have to have 2 Team Projects and therefore, the client would have 2 TP's. So perhaps the better way to do it is each unique project get's it's own TP. So a client could (and in many cases probably would) have more than 1 TP. You can use "areas" to subdivide your team project, as well. So if you had two projects for the same client, you could have an area "Project A" and an area "Project B", and then individual queries for each that filters by area. I generally use the Scrum template. We're veering off into territory for the Agile megathread, but make sure you read up on how to estimate your PBIs accurately.
|
|
#
¿
Sep 5, 2013 22:17
|
|
|
Mr. Crow posted:I hate to use the word because its very cliche, but we have a very agile process. You shouldn't use the term Agile if you're not actually doing Agile development.
|
|
#
¿
Oct 1, 2013 16:39
|
|
|
Plorkyeran posted:After-the-fact code reviews pretty much aren't code reviews in the sense that most people mean. Requiring that all code be reviewed before it's pushed to trunk results in a pretty fundamentally different workflow. Yeah, I've always enforced code review before it even leaves a dev branch. If someone wrote lovely code, why should that code escape into my other branches?
|
|
#
¿
Oct 1, 2013 17:03
|
|
|
i barely GNU her! posted:Does TFS (2010) not pull down folders not referenced in a solution or csproj? I added a couple of packages from NuGet (which of course added references in csproj files to stuff in the packages folder) and another developer was complaining that the references were missing and he went and added references to the local copies of the DLLs in the project bin folders. I went into TFS and saw the files were checked in before he brought it up, just want to check that there could be a technical reason before I call him a moron. It depends. If you open up a solution directly from source control and the solution is bound to source control, VS will prompt you to download the projects in the solution if they aren't already on disk. In that case, you'll only get the things "visible" to the solution. That doesn't include external assembly references. If you just do a "get latest" from source control on a folder, it'll pull everything in the folder down.
|
|
#
¿
Nov 2, 2013 23:21
|
|
|
Unpopular opinion from a ALM consultant focused on Microsoft: Consider TFS. Express edition is free for up to 5 developers, and it has awesome IDE integration for Visual Studio and Eclipse. If your co-workers aren't already using source control, Git is going to be a hard sell. You can move everything into Git easily enough if you end up hating TFS, though.
|
|
#
¿
Nov 7, 2013 16:32
|
|
|
No Safe Word posted:TFS being down right now is crippling as poo poo for our team and I'm angry that we use TFS when we did have git up and running (but due to the fact that we're actually Microsoft partners and at the time the TFS + git option didn't exist, we swapped). Yeah, that's pretty bad, but it's not like Github never has downtime. And TFS Express is hosted on-prem, anyway, so if it goes down it's your own fault.
|
|
#
¿
Nov 8, 2013 17:33
|
|
|
Suspicious Dish posted:Even if GitHub goes down, I can still work. I can still pull somebody's remote branch if they want me to test something. Local workspaces solve that, if you're using VS2012.
|
|
#
¿
Nov 8, 2013 18:12
|
|
|
No Safe Word posted:That doesn't make it not-centralized and suddenly immune to a centralized system causing a team-wide outage of their source control capabilities. Well, local workspaces won't save you if you're trying to access something that's on another person's machine. They just keep you from having to deal with everything being un-check-outable because you can't communicate to a server.
|
|
#
¿
Nov 8, 2013 20:48
|
|
|
Plorkyeran posted:Ignoring failures is definitely the wrong solution. If external people supplying broken xpath queries isn't a problem then your unit tests shouldn't be using them at all, and if it is a problem then you should be treating them as code changes with your CI system sending angry emails to people who break them or rejecting changes to them which would break the tests. Treating "code changes" and "data changes" as totally different sorts of things is rarely actually sensible. This is the correct answer.
|
|
#
¿
Dec 6, 2013 18:22
|
|
|
Tha Chodesweller posted:You're misunderstanding the problem. Perfectly valid code check-ins are failing and being rejected because of a database change that the person checking in did not submit. We're not trying to ignore test failures, we're trying to prevent workflow from grinding to a halt because someone who's not a developer made a half-minded change to a xpath. If a database change is failing your test, it's not a unit test. The best solution is to decouple your tests from your database.
|
|
#
¿
Dec 6, 2013 18:37
|
|
|
gariig posted:Most likely these aren't unit tests but are integration tests. A bad XPath put into a Staging or QA environment shouldn't be breaking your unit tests. They shouldn't be depending on what is in a database that data should be mocked/faked out. Maybe take all of the tests that use these XPath values from your database and put them into another project that your CI runs occasionally and only have unit tests be ran on check-in where the code portion of the build fails. Yeah, it gets tricky when you have tests that depend on your database. Ideally, you have your database changes source controlled and handled through SSDT deployments, not by having some random person go and update rows. Your CI build ends up looking like this:
Your nightly build looks like this:
Tha Chodesweller posted:That's actually a good solution. Any way to trigger this build any time the aforementioned build completes? You can also set up test categories and specify that only certain test categories should be run as part of a build. If your build and tests run fast, just set up three builds:
Then you'll get the feedback on your failing integration tests pretty rapidly, but your devs won't end up blocked. [edit] I'm actually not sure how gated checkin and rolling build will interact with each other, I've never tried it before. [edit2] Regarding Gated Checkin: I really strongly recommend against gated checkins unless your devs have a history of checking in total noncompiling garbage. New Yorp New Yorp fucked around with this message at 18:54 on Dec 6, 2013 |
|
#
¿
Dec 6, 2013 18:42
|
|
|
No Safe Word posted:So am I completely missing something or is TFS actually requiring me to download the branches that I want to delete before it actually allows me to delete it? I'm pruning some completed branches but I don't have them checked out locally, so it's not giving me the option in VS to delete that branch. When I download it, it becomes available. Just map the branch, do a non-recursive get with the "tf get" command, then you can delete it. It's weird, I know.
|
|
#
¿
Dec 11, 2013 20:15
|
|
|
Visual Studio Online (formerly Team Foundation Service) isn't a bad choice, even if you just want to use it as a Git repo and ignore all of the other stuff it can do. Plus it's free.
|
|
#
¿
Jan 29, 2014 21:12
|
|
|
paberu posted:I was thinking of splitting the project into Mercurial and SVN anyway, it should work fine for a tiny team. Having two totally different source control systems is really stupid, especially within the same team. Pick one and use it.
|
|
#
¿
Jan 30, 2014 15:29
|
|
|
johnduhart posted:Has anyone here used ClearCase/ClearQuest before? We really wanted to use TFS (we've developing a .NET product) but corporate is forcing us to use this. ClearCase is terrible, and my company migrates people off of it into TFS all the time.
|
|
#
¿
Feb 4, 2014 17:31
|
|
|
prefect posted:Beyond Compare is awesome, and well worth the money (it's like thirty bucks). Yeah, I use Beyond Compare. I've also been playing with Semantic Merge, which is pretty awesome for .NET/Java. It actually parses your code and merges based on that, instead of just straight text compare. If you move a method from file A to file B, but someone else has modified the method when it was still in file A, it'll successfully merge that.
|
|
#
¿
Feb 14, 2014 17:50
|
|
|
Megaman posted:Can you give me one reason how git arcane? Hughlander posted:
|
|
#
¿
Feb 19, 2014 23:47
|
|
|
Sir_Substance posted:I have a deep and abiding hatred of git because I feel that the purpose of version control is to make managing my code versions and working with other people on the same codebase effortless. If there are two things git doesn't do, its those. It is arcane by the standard of commands set by every other VCS, and I've seen way more git repos hosed by an accidental but well meaning rookie command then any other system. I'm with you on this. I steer my clients away from using Git if they're not using it already. Source control should be simple and easy to use; Git is neither. Every SCM platform has its own set of challenges, but Git's challenge is "actually using it for day to day work productively".
|
|
#
¿
Feb 20, 2014 02:20
|
|
|
Megaman posted:In my experience people who fight git and mercurial just refuse to learn the tools out of sheer stubbornness for no reason. I know how to use Git, I just dislike it. I work in the Microsoft world, though, so there are plenty of SCM tools that are much easier to use available. Now that Git is a first-class citizen in TFS2013, we actually had a company meeting to start figuring out when we should recommend Git to people over the default centralized version control option. We couldn't think of very many cases where the distributed nature of Git is a big enough win over centralized VC to warrant the additional complexity.
|
|
#
¿
Feb 20, 2014 04:51
|
|
|
down with slavery posted:You've posted a lot about TFS in this thread, but you haven't really convinced me that it's worth the thousands Microsoft is asking. What is so much easier in TFS than git? Well, the full value of TFS in all of the things it does in addition to version control -- project management, build, deployment, etc. VC is really a small piece of TFS. In any case, the workflow with centralized VC is more straightforward. You have a central code repository, you make a local copy of it, and then you make changes to it. A different branch in TFS is just a different set of files in your file system (it's smarter than that internally, but the internal representation of the files and change history is totally opaque and irrelevant to me as a developer). There's no need to check out a different branch to make sure you're working on the right code. When you're done, merge your changes and check it back in. Changesets are sequential and can't be reordered. Cherry-picking changesets for merging between branches is considered a bad practice. If you need to store work in progress that's not ready to actually be checked back in, you can shelve it temporarily, then unshelve it later. The Git interface in Visual Studio is actually really good for the basic operations, but you still have to drop to a command line for the trickier stuff like rebasing. When I talk about Git being harder for your average developer to use, I'm not making poo poo up to prove a point. I've worked with several clients this year who recently started using Git, and most of them had productivity issues because their devs were devoting more time than they thought was acceptable to working through source control issues. The one client who had no problems with Git had put so much red tape and process in place that they were essentially using Git as a centralized version control system. I'm not saying that no one should use Git. If you and your teams are having awesome success and no friction using it, more power to you. My experience so far has been the opposite, that's all. It does seem like there's a horrible elitist attitude in the Git community that if you don't like it, it means that you're a stupid lovely idiot who has no business being a professional developer. down with slavery posted:I thought this was the version control thread not the "confess your weaknesses" thread I thought this was the version control thread not the "get oddly defensive over people who have differing opinions" thread.
|
|
#
¿
Feb 20, 2014 06:04
|
|
|
down with slavery posted:What the gently caress are you talking about? The biggest benefit of centralized version control over distributed version control is that the overall workflow is simpler. Get code from central repo. Make changes. Merge if necessary. Check in. It very rarely deviates from that, which is good when your company consists of hundreds or thousands of developers of wildly differing levels of experience, skill and dedication. These are folks that don't want or need the power (and associated workflow complexity) that DVCS delivers. New Yorp New Yorp fucked around with this message at 13:03 on Feb 20, 2014 |
|
#
¿
Feb 20, 2014 12:59
|
|
|
Megaman posted:There's really no point to using windows at work unless you have a program that absolutely requires it, I can't think of any offhand though that wouldn't also be available for Linux in some form or another. There's also no reason to use it at home unless you're playing games, and even then you can use wine. Did I just get teleported to Slashdot in 2006?
|
|
#
¿
Feb 28, 2014 16:06
|
|
|
|
| # ¿ May 14, 2024 22:26 |
|
|
hirvox posted:For version control and work item tracking purposes, VSO is indistinguishable from on-premises TFS. The only real restriction is that you have no control over the Build Controller/Agent servers that Team Builds run on. Automatic unit test runs and deploying to web-accessible servers (preferably Azure) is still doable, but compliling projects with loads of dependencies, running tightly-coupled integration tests and deploying to on-premises, heavily firewalled servers can be difficult. The other restriction is that Microsoft's new release management package doesn't support VSO yet -- it requires an on-prem TFS instance still. It's weird because it really doesn't do anything other than pull down build information from TFS, so I'm assuming it's a limitation in how the original developers handled authentication. I wouldn't be surprised if Update 2 changes that. New Yorp New Yorp fucked around with this message at 19:54 on Apr 6, 2014 |
|
#
¿
Apr 6, 2014 19:51
|
|