Is there a white paper explaining why Team Foundation Version Control sucks ?
-
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
"Use the right tool for the right job." Git is not the right tool for any job I've had, but TFS is. I have never had a job in which a distributed version control system would make a positive difference. I found TFS to be much more usable than Git -- TFS just worked. Git was a step back. Maybe the Visual Studio Git integration will some day be up to what we have with TFS. For myself, my experience is more like: CMS (OpenVMS) -> look at VSS, reject it -> look at Subversion, reject it, get forced to use it anyway -> rolled my own* -> Subversion again, but with Tortoise -> TFS -> get forced to use Git -> roll another of my own What makes CMS and TFS superior to VSS, Subversion, and Git is Classes (in CMS) and Labels (in TFS). The others do not have an equivalent feature. TFS also has integrated ticketing and a .net API, which makes it the best system I currently know of. A feature which CMS (OpenVMS only) has which the others don't is the ability to target multiple libraries (repositories) at the same time -- I wish the others would add that, but they won't. CMS also supports Groups, which the others don't. HP has again killed the OpenVMS Hobbyist program, so I can't give any demos of how great CMS is. * I may have mentioned this before. I began it in 2009 (as I recall) and I got it to a vaguely usable state before reaching a major decision point and stalled. The major features are pretty much that of CMS. Occasionally, I think about getting back on it.
-
I worked with a strong proponent of Git. "Git's way more powerful". I understand that argument, but if TFVS/TFS/whatever does everything I need it to, with some simple right-click menus that aren't confusing...the extra power Git offers is lost on me...
dandy72 wrote:
"Git's way more powerful"
Yeah, that only helps if you actually need more power. Maybe you need more control, and less power would be a benefit instead.
dandy72 wrote:
the extra power Git offers is lost on me
The only "extra power" I know it has is that it's distributed, and I don't need that.
-
"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.
dandy72 wrote:
If MS can't do a decent job
I agree. The Git integration in Visual Studio is much weaker than TFS'. I hope they improve it.
-
dandy72 wrote:
If MS can't do a decent job
I agree. The Git integration in Visual Studio is much weaker than TFS'. I hope they improve it.
-
You're doing it exactly the way you should, including deleting temporary work branches. And, I can 100% see why you'd want to have local configs shared somewhere. The question is where? Should that be in the repo? From a security perspective some will say, never put connection info anywhere in a repo / where it's not needed, and I personally fall into that camp. Especially because git will never forget changes and booboos happen. But then, life happens too. :laugh: So, given that, you got a couple options: 1. You can still push a stash remotely, but it's a pain compared to other SCMs. But if you want ideas, scroll down until you see Scott Weldon's answer. You can totally work with detached heads and commits in git, as long as you remember the short SHA, where git puts stuff, etc. Of course, this is a pain to do. But if you're just looking to backup/share something every now and again, it may be worth it. 2. If the structure of that file is the most important thing (so you can remember what settings you need), you can always create a template settings file that contains everything but the actual connection values and put that into the repo permanently. This is what I do, using something like dotenv (been the web world lately). But, there will be a template file that shows everything that needs to go in the actual config that gets committed while the real values are saved elsewhere. This way you can share the how but not the what. I guess at the end of the day, the difference is, for connection info, I'll put that in Confluence or something if it needs to be shared. Both ideas of keeping it in the shared repo (all in one place) and keeping out out of the shared repo (security) have merit ya know.
Jeremy Falcon
Thanks for your reply. Unfortunately it's not just connection strings but IIS port numbers. These are specific to the developer's machine. I've decided that the fastest way forward is to write an automated script that updates a dev's config files. Devs will use this script at the start of their workday. But IMHO this is a workaround for something (remote stashes) an SCM should provide out of the box. :) /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
-
Thanks for your reply. Unfortunately it's not just connection strings but IIS port numbers. These are specific to the developer's machine. I've decided that the fastest way forward is to write an automated script that updates a dev's config files. Devs will use this script at the start of their workday. But IMHO this is a workaround for something (remote stashes) an SCM should provide out of the box. :) /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
Ravi Bhavnani wrote:
But IMHO this (remote stashes) is a workaround for something an SCM should provide out of the box.
Fair enough. Thanks for being the first person to say something legit though. There's another dude going on for days who clearly doesn't know what he's talking about it. So, your chat was totally refreshing.
Jeremy Falcon
-
Then show me that Tags are as flexible as Labels. So far you have not, even though I have asked you to. To this point, all I have seen you doing is denying that Labels are more flexible than Tags -- even though they are. I have tried to explain the flexibility of Label several times in this thread, but it seems to have fallen on deaf ears. Maybe the failing is on my side, so I'll try to explain it with an example... Let's say I have a repository, and I check in v1 of files A, B, and C. With Git (or Subversion) I can create a Tag which represents a snapshot of v1 of those three files. Then I check in v2 of those files. With Git (or Subversion) I can create a Tag which represents a snapshot of v2 of those three files. Correct so far? Yes? If I am using TFS (or CMS), I can create Labels (Classes) which do exactly that, but I can also create Labels (Classes) which: Contain v1 of file A and v2 of file B and does not include file C. Contain v2 of file A and v1 of file B and does not include file C. Labels and Classes can also be modified after they have been created -- perhaps after v3 has been checked in. My understanding is that Tags in Git and Subversion cannot do that. Am I wrong? Whether or not you in particular have a need for this feature is irrelevant. CAN Tags (or some other feature I don't know about) in Git do that? I have seen no evidence in the documentation that it can. If so, where does the documentation explain how to do it? IF Git actually does have a feature which provides the functionality of Labels (in TFS) or Classes (in CMS), then I need to know. But, to my knowledge, it is not Tags and so far you have not addressed that question.
This is the first time you actually talked to me. The fact you get all uppety over your poor communication skills is pretty sad man. So now, I'm going to freaking repeat myself. If you choose to ignore me twice, that's on you. But you're wasting my time here and this point I'm going to bill you. This is childish and ridiculous. NOW, SINCE YOU ARE TALKING DOWN TO ME... (GO AHEAD AND DENY IT) I'LL USE BOLD TOO.
PIEBALDconsult wrote:
Labels and Classes can also be modified after they have been created -- perhaps after v3 has been checked in.
I've addressed one way to do that, but I'll explain another. IF YOU DO NOT UNDERSTAND GIT THAT'S OK. JEEZE. But, if you need to do that, you can create a commit and tag it based on files that are 100% cherry picked from different commits or DIFFERENT VERSIONS OF COMMITS. THIS IS 100% DOABLE SO NEXT TIME READ MY POST.
PIEBALDconsult wrote:
Labels and Classes can also be modified after they have been created -- perhaps after v3 has been checked in.
THIS IS NOT A GOOD THING. GIT WORKS MORE LIKE THE BLOCK CHAIN. IF YOU WANT TO MODIFIY THAT THEN CREATE A NEW COMMIT WITH WHATEVER CHERRY PICKED FILES YOU WANT AND RECREATE THE TAG OFF THAT.
PIEBALDconsult wrote:
Am I wrong?
YES! In two ways, the second being you don't actually read the posts you're arguing on. I don't care anymore if you deny that, any intelligent person knows the truth. Anything else you want to say? I've already lost all respect for you. Jeeze. This is the reason I loathe CP at times. What a waste of life.
Jeremy Falcon
-
Then show me that Tags are as flexible as Labels. So far you have not, even though I have asked you to. To this point, all I have seen you doing is denying that Labels are more flexible than Tags -- even though they are. I have tried to explain the flexibility of Label several times in this thread, but it seems to have fallen on deaf ears. Maybe the failing is on my side, so I'll try to explain it with an example... Let's say I have a repository, and I check in v1 of files A, B, and C. With Git (or Subversion) I can create a Tag which represents a snapshot of v1 of those three files. Then I check in v2 of those files. With Git (or Subversion) I can create a Tag which represents a snapshot of v2 of those three files. Correct so far? Yes? If I am using TFS (or CMS), I can create Labels (Classes) which do exactly that, but I can also create Labels (Classes) which: Contain v1 of file A and v2 of file B and does not include file C. Contain v2 of file A and v1 of file B and does not include file C. Labels and Classes can also be modified after they have been created -- perhaps after v3 has been checked in. My understanding is that Tags in Git and Subversion cannot do that. Am I wrong? Whether or not you in particular have a need for this feature is irrelevant. CAN Tags (or some other feature I don't know about) in Git do that? I have seen no evidence in the documentation that it can. If so, where does the documentation explain how to do it? IF Git actually does have a feature which provides the functionality of Labels (in TFS) or Classes (in CMS), then I need to know. But, to my knowledge, it is not Tags and so far you have not addressed that question.
I deleted my reply because I don't want to be a part of this conversation anymore. You can think what you want. I don't care. You're flying solo now.
Jeremy Falcon
-
I deleted my reply because I don't want to be a part of this conversation anymore. You can think what you want. I don't care. You're flying solo now.
Jeremy Falcon
Jeremy Falcon wrote:
This is the first time you actually talked to me. The fact you get all uppety over your poor communication skills is pretty sad man. So now, I'm going to freaking repeat myself. If you choose to ignore me twice, that's on you. But you're wasting my time here and this point I'm going to bill you. This is childish and ridiculous. NOW, SINCE YOU ARE TALKING DOWN TO ME... (GO AHEAD AND DENY IT) I'LL USE BOLD TOO. PIEBALDconsult wrote: Labels and Classes can also be modified after they have been created -- perhaps after v3 has been checked in. I've addressed one way to do that, but I'll explain another. IF YOU DO NOT UNDERSTAND GIT THAT'S OK. JEEZE. But, if you need to do that, you can create a commit and tag it that 100% is cherry picked from different commits or DIFFERENT VERSIONS OF COMMITS. THIS IS 100% DOABLE SO NEXT TIME READ MY POST. PIEBALDconsult wrote: Labels and Classes can also be modified after they have been created -- perhaps after v3 has been checked in. THIS IS NOT A GOOD THING. GIT WORKS MORE LIKE THE BLOCK CHAIN. IF YOU WANT TO MODIFIY THAT THEN CREATE A NEW COMMIT WITH WHATEVER CHERRY PICKED FILES YOU WANT AND RECREATE THE TAG OFF THAT. PIEBALDconsult wrote: Am I wrong? YES! In two ways, the second being you don't actually read the posts you're arguing on. I don't care anymore if you deny that, any intelligent person knows the truth. Anything else you want to say? I've already lost all respect for you. Jeeze. This is the reason I loathe CP at times. What a waste of life.
Thank you for finally acknowledging that you understand that Tags in Git are not the same as Labels in TFS and Classes in CMS. Now please stop telling people that they are, because that's wrong. Labels and Classes are superior to Tags. Perhaps you are saying that Tags in Git are better than Tags in Subversion. I hope that's true anyway.
Jeremy Falcon wrote:
This is the first time you actually talked to me.
No, it isn't. I have replied to many of your responses, but you have not addressed my concerns until now.
Jeremy Falcon wrote:
I've addressed one way to do that
No, you haven't. All I have seen you do until now is repeat what I already know from the documentation.
Jeremy Falcon wrote:
tag it based on files that are 100% cherry picked from different commi
-
"Use the right tool for the right job." Git is not the right tool for any job I've had, but TFS is. I have never had a job in which a distributed version control system would make a positive difference. I found TFS to be much more usable than Git -- TFS just worked. Git was a step back. Maybe the Visual Studio Git integration will some day be up to what we have with TFS. For myself, my experience is more like: CMS (OpenVMS) -> look at VSS, reject it -> look at Subversion, reject it, get forced to use it anyway -> rolled my own* -> Subversion again, but with Tortoise -> TFS -> get forced to use Git -> roll another of my own What makes CMS and TFS superior to VSS, Subversion, and Git is Classes (in CMS) and Labels (in TFS). The others do not have an equivalent feature. TFS also has integrated ticketing and a .net API, which makes it the best system I currently know of. A feature which CMS (OpenVMS only) has which the others don't is the ability to target multiple libraries (repositories) at the same time -- I wish the others would add that, but they won't. CMS also supports Groups, which the others don't. HP has again killed the OpenVMS Hobbyist program, so I can't give any demos of how great CMS is. * I may have mentioned this before. I began it in 2009 (as I recall) and I got it to a vaguely usable state before reaching a major decision point and stalled. The major features are pretty much that of CMS. Occasionally, I think about getting back on it.
I wish I could say that my experience was that TFS "just worked", because I found the opposite to be true. I've used (and administrated) all of these source control systems: * Perforce * ClearCase * TFS * git (in CLI and also via BitBucket, GitLab, GitHub) * svn * SourceSafe (which is by far the worst of all of these) * MKS Source Integrity * PVCS * CVS * sccs * CMS (VAX) Of these, TFS is a bottom-quartile experience. If you're heavily into the Windows dev train, then it bumps up in usefulness just a hair, but it still sucks. There are 3 items on this list that I'd quit my job over rather than use again, and TFS is one of them.
-
I wish I could say that my experience was that TFS "just worked", because I found the opposite to be true. I've used (and administrated) all of these source control systems: * Perforce * ClearCase * TFS * git (in CLI and also via BitBucket, GitLab, GitHub) * svn * SourceSafe (which is by far the worst of all of these) * MKS Source Integrity * PVCS * CVS * sccs * CMS (VAX) Of these, TFS is a bottom-quartile experience. If you're heavily into the Windows dev train, then it bumps up in usefulness just a hair, but it still sucks. There are 3 items on this list that I'd quit my job over rather than use again, and TFS is one of them.
Br.Bill wrote:
If you're heavily into the Windows dev train
Oh, yes, I agree with that. I should have added a qualifier. I doubt anyone would use TFS if they are not using Visual Studio. I was mainly using SSIS, which necessitated the use of Visual Studio anyway. Trying to use Git with SSIS was very problematic (for me anyway, there were other issues involved [e.g. corporate politics] which didn't help) and I had to create a nasty work-around to get it to work. I have never had a choice of version control system, they are always dictated by management. As to writing code (C/C++ C# etc.) I prefer not to use Visual Studio at all. Similarly for SQL code -- I develop that in SSMS, not Visual Studio, then I have to generate scripts via the SMO API in .net to get them right.