Is there a white paper explaining why Team Foundation Version Control sucks ?
-
Git sucks. TFS is awesome.
Strongly agree. :thumbsup: /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
-
Gotcha. Since git is gaining so much in popularity, I just had to ask. Seems like everyone's moving in that direction, and not the opposite way. Personally, I just use TFS through Visual Studio and I'm absolutely fine with it. Git, despite the support built into VS for it, seems to really encourage people to work at a command prompt. And frankly, when things go wrong, I'd rather figure out menu options than command line switches.
At work we moved from TFVC to Git in 2018. But all my personal code is hosted in TFVC. I personally prefer its ease of use. /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
-
At work we moved from TFVC to Git in 2018. But all my personal code is hosted in TFVC. I personally prefer its ease of use. /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
-
I've gotten used to git (Mostly thanks to the GitKraken product), but I do long for the days of locking a file so no one else could modify while I was.
I’ve given up trying to be calm. However, I am open to feeling slightly less agitated. I’m begging you for the benefit of everyone, don’t be STUPID.
MarkTJohnson wrote:
I do long for the days of locking a file so no one else could modify while I was
That 100% does not scale. If you're a team of two... fine. If you're an enterprise that flat-out fails on so many levels. You can't block one person from doing work while you lock a file. It's better to just learn how to merge.
Jeremy Falcon
-
Git sucks. TFS is awesome.
Git is awesome. I know for a fact the only peeps that hate it are the peeps that don't know it. Name one thing TFS does better... I'm waiting.
Jeremy Falcon
-
Dear dog, I thought GIT sucked... but the winner goes to TFVC It seems in all my years of development, I've moved forward with Version Control. RCS -> CVS -> Subversion -> git but going from git to TFVC feels like a step back. Maybe there's just something I don't get from the system.
CI/CD = Continuous Impediment/Continuous Despair
Stick with git. It'll take you much further and make you more flexible.
Jeremy Falcon
-
MarkTJohnson wrote:
I do long for the days of locking a file so no one else could modify while I was
That 100% does not scale. If you're a team of two... fine. If you're an enterprise that flat-out fails on so many levels. You can't block one person from doing work while you lock a file. It's better to just learn how to merge.
Jeremy Falcon
I know how to merge, I just wish I understood why some things throw merge conflict when there is no conflict, you are just changing a particular line. >>>>> New Code This line says B ===== This line says A <<<<< Old Code Why is that a merge conflict?
I’ve given up trying to be calm. However, I am open to feeling slightly less agitated. I’m begging you for the benefit of everyone, don’t be STUPID.
-
Gotcha. Since git is gaining so much in popularity, I just had to ask. Seems like everyone's moving in that direction, and not the opposite way. Personally, I just use TFS through Visual Studio and I'm absolutely fine with it. Git, despite the support built into VS for it, seems to really encourage people to work at a command prompt. And frankly, when things go wrong, I'd rather figure out menu options than command line switches.
Get yourself a Git GUI, SourceTree, GitKraken, etc. Here's a list 10 Best Git GUI Clients for Windows in 2023[^]
I’ve given up trying to be calm. However, I am open to feeling slightly less agitated. I’m begging you for the benefit of everyone, don’t be STUPID.
-
Get yourself a Git GUI, SourceTree, GitKraken, etc. Here's a list 10 Best Git GUI Clients for Windows in 2023[^]
I’ve given up trying to be calm. However, I am open to feeling slightly less agitated. I’m begging you for the benefit of everyone, don’t be STUPID.
"10 Best Git GUI Clients"? :wtf: 10? That's...not good. IMO. I use Visual Studio. I don't want to launch a separate tool just for source control. A Git client ought to be integrated with the tool that lets you write that source. If MS can't do a decent job (and that seems to be the case), then it's got an extension architecture.
-
Dear dog, I thought GIT sucked... but the winner goes to TFVC It seems in all my years of development, I've moved forward with Version Control. RCS -> CVS -> Subversion -> git but going from git to TFVC feels like a step back. Maybe there's just something I don't get from the system.
CI/CD = Continuous Impediment/Continuous Despair
I haven't run into any issues with using Git. I use Git via Visual Studio and Azure DevOps Repos, and to me, it is seamless. I get the idea of a local repo and a remote repo, with branching, that Git uses. I have used Bitbucket and Subversion, liked both, and found I like Git more, especially for team use.
-
Gotcha. Since git is gaining so much in popularity, I just had to ask. Seems like everyone's moving in that direction, and not the opposite way. Personally, I just use TFS through Visual Studio and I'm absolutely fine with it. Git, despite the support built into VS for it, seems to really encourage people to work at a command prompt. And frankly, when things go wrong, I'd rather figure out menu options than command line switches.
I've been using Git in VS for several years, and never had to use a command prompt for anything. The UI always provided everything I needed.
-
I know how to merge, I just wish I understood why some things throw merge conflict when there is no conflict, you are just changing a particular line. >>>>> New Code This line says B ===== This line says A <<<<< Old Code Why is that a merge conflict?
I’ve given up trying to be calm. However, I am open to feeling slightly less agitated. I’m begging you for the benefit of everyone, don’t be STUPID.
Depends on the line and the direction of the merge. Something like that isn't always a merge conflict. Sometimes it is... usually more so on a rebase than a merge in my experience. I've even seen whitespace trip git up. So, it's not perfect in the fact it will always be automatic. That being said, even if git were bad at merges (it's not... it's better than most)... handling a conflict here and there is still better than preventing people from working.
Jeremy Falcon
-
I've been using Git in VS for several years, and never had to use a command prompt for anything. The UI always provided everything I needed.
More power to you. Everybody should be blessed with that sort of experience. Maybe what we did deviated from what was made available through the GUI, but we were strongly encouraged (by those who were familiar with the system) to "just do everything from the command line".
-
Git is awesome. I know for a fact the only peeps that hate it are the peeps that don't know it. Name one thing TFS does better... I'm waiting.
Jeremy Falcon
I fully agree. Based purely on my experience, I'll readily admit I'm not a fan of Git, but fully acknowledge that this is entirely because I don't know it well enough. I have zero doubt, at this stage, Git is the superior product. I worked with a guy who *loved* it, and his enthusiasm for it was contagious. Who gets excited about TFS?? :-)
-
More power to you. Everybody should be blessed with that sort of experience. Maybe what we did deviated from what was made available through the GUI, but we were strongly encouraged (by those who were familiar with the system) to "just do everything from the command line".
That is not unusual. There are a lot of people whose experience came up through non-Windows OSs that had nothing but a command line in most cases. They tend to want to force that 1990s way of interface on others now. My point is that using Git in Visual Studio has been around with a GUI interface for years. If the less informed (like those telling you to use command line) choose not to use it, that is their problem, and it sounds like they made it your problem with which to deal. Sorry they hold you back like that.
-
That is not unusual. There are a lot of people whose experience came up through non-Windows OSs that had nothing but a command line in most cases. They tend to want to force that 1990s way of interface on others now. My point is that using Git in Visual Studio has been around with a GUI interface for years. If the less informed (like those telling you to use command line) choose not to use it, that is their problem, and it sounds like they made it your problem with which to deal. Sorry they hold you back like that.
Maybe I haven't made it sufficiently clear in the thread. At the time, the company I worked for was on contract with Microsoft. You know, makers of VS and TFS. Those Microsoft people we contracted with were using Git, not TFS, and there was a very strong push, coming from them, to do everything at a command prompt. These are not folks who don't know Microsoft products, or how to use VS or TFS. Maybe I shouldn't be saying this publicly, but I'm not naming who I work for, nor the team at Microsoft we were working with. But internally, there's more and more support for Git - at TFS's expense.
-
Maybe I haven't made it sufficiently clear in the thread. At the time, the company I worked for was on contract with Microsoft. You know, makers of VS and TFS. Those Microsoft people we contracted with were using Git, not TFS, and there was a very strong push, coming from them, to do everything at a command prompt. These are not folks who don't know Microsoft products, or how to use VS or TFS. Maybe I shouldn't be saying this publicly, but I'm not naming who I work for, nor the team at Microsoft we were working with. But internally, there's more and more support for Git - at TFS's expense.
You were clear. Microsoft, especially under the current CEO, suffers from a lot of command line, Linux-oriented developers and program managers who know little or nothing about MS’s past with GUI tools. Even with visual tools that do all that is necessary, those oriented towards command line tools will still pretend a command line is needed. I am not surprised you had folks at MS tell you that. I agree that they were sincere in their advice, just sincerely wrong. That same mentality is why the software engineers (Alan Cooper’s team) back in the 1990s created a very useful GUI builder for Visual Basic (later ported to Visual Studio). But when extending Visual Studio to mobile apps (Xamarin Forms/MAUI) and web (Blazor), MS software engineers of the caliber they had in the 1990s and 2000s were long gone, and the command line oriented software engineers and program managers were not advanced enough to know how to build GUI builders for mobile and web, or to understand the significant value in them. MS development tools suffer from not having visual designers, limited to the archaic “hot reload”. The advice given to you about command line use of Git fits right in with a much wider engineering deficit at MS.
-
Git is awesome. I know for a fact the only peeps that hate it are the peeps that don't know it. Name one thing TFS does better... I'm waiting.
Jeremy Falcon
Labels. Git doesn't have them at all and they are critical. And an API / .net integration. And integrated ticketing. Edit: Here's what the Users' Manual for CMS has to say about Classes (which are very like Labels in TFS.)
5.1.2 Classes
A class is a set of specific generations of elements that can be manipulated as
a unit. A class can hold only one generation of any element.
You use classes to represent the state of development of a system or set of
elements at a particular time or stage. You can think of a class as a picture
taken of a library at a particular time. For example, you might create a class
named FIRST_DRAFT that contains only those generations of elements that
were used in producing the first draft of a manual.
Typically, you create a class to contain generations of all the components of a
software system for a release version of a product. You can establish classes
for different stages or milestones. For example, you could establish one class
for implementation, a second for testing, and a third for generations that
have completed the first two stages. As each module progresses through each
stage, you assign each generation to an appropriate class; thus, you can easily
determine your progress by displaying the contents of the different classes, and
you can later reconstruct any stage of development.
Once you insert an element generation into a class, further changes made to
the element are not reflected in the contents of that class.HP DECset for OpenVMS Guide to the Code Management System Order Number: AA–KL03H–TE July 2005 In particular: "or set of elements" -- the developer has full control over which generations of which elements are included in the class. Note that VSS does not have such a feature, but it was included in TFS.
CREATE CLASS class-name[,...] ‘‘remark’’
Command Qualifiers Defaults
/[NO]LOG /LOG
/OCCLUDE[=option,...] /OCCLUDE=ALL
Creates one or more classes. After creating a class, you can place any related
set of element generations in that class by using the INSERT GENERATION
command. The CREATE CLASS command does not automatically place any
generations in the created class. For more information on classes, see the
HP DECset for OpenVMS Guide to the Code Management System.HP DECset for OpenVMS Code Management System Reference Manual Order Number: AA–QJEVC–TK July 2005 The phrase, "any related set of element generations", may give the impression that there already has to be
-
Dear dog, I thought GIT sucked... but the winner goes to TFVC It seems in all my years of development, I've moved forward with Version Control. RCS -> CVS -> Subversion -> git but going from git to TFVC feels like a step back. Maybe there's just something I don't get from the system.
CI/CD = Continuous Impediment/Continuous Despair
Maximilien wrote:
but going from git to TFVC feels like a step back.
Because it is a step back... TFVC is a centralized version control system, like Subversion. You basically went from Git, which is decentralized, back to a different flavor of Subversion. Microsoft has been ditching TFVC in favor of Git for years now.
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
Dear dog, I thought GIT sucked... but the winner goes to TFVC It seems in all my years of development, I've moved forward with Version Control. RCS -> CVS -> Subversion -> git but going from git to TFVC feels like a step back. Maybe there's just something I don't get from the system.
CI/CD = Continuous Impediment/Continuous Despair
When I was managing a dev team of 6 on a pretty large codebase, we used TSVC and later Git. TSVC worked very well for us, and was relatively easy to manage. The obvious difference was centralised vs. decentralised/distributed. We didn't need that complexity. Torvaulds designed Git because he was managing many developers spread around the world in different time zones, and the distributed nature of Git matched that. You pick the tool suited to the job in hand. Moving from any tool you are familiar and competent with to another is often going to feel awkward, if not a backward step, until you are experienced with the new one. Persevere and you will eventually find they both have their strengths and weaknesses. With regard to "must use commandline" (or Gui) I find the professional elitism or evangelism that pervades so many software developers irksome and irritating, and use of the command line as some sort of implied superiority especially so. I use the command line myself when it's easier or has options I need that are not supported by the available Gui tools, and Gui tools when they are more convenient. The commanline is useful for automating processes with scripts, most other times it's easier to use a Gui. Just pick the approach that suits the circumstances.
