Is there a white paper explaining why Team Foundation Version Control sucks ?
-
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
Exactly. I dunno about you, but a good dev does frequent (ok, not too frequent) commits. I don't miss slow commits at all. :laugh: A commit is a check-in for the non-git folk among us.
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.
Part is you can't just "learn" how to merge really. What needs to happen when the merge involves code you didn't author is often not so clear. So it's a sudden detour to getting anything productive done and we resent that. Sometimes merging can be massively painful and it just rises out of nowhere. It's semi-predictable you may have to merge but not at all predictable what that might actually mean in terms of time/effort. Will say though that some of the architecturally 'bloaty' paradigms help aid in merging being less a hassle because bits that may have been changes/revisions before are totally new bits. Basically, rather merge the new stuff than one of the old megamonolith apps.
-
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:
of locking a file
I always saw that need as a very likely issue with architecture, design and/or project management. For large teams the code should not be laid out in a way that results in this being a problem in any substantial way. And for those cases where one or two files are central then it should be possible to layout out the project tasks so one can touch that file very quickly. For example if an enum is used widely then it should be in its own file (and perhaps own project/jar) and the project task should be to update it and do nothing else for that task.
-
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.
MSBassSinger wrote:
back in the 1990s created a very useful GUI builder for Visual Basic
Having worked on a system that specifically was intended to build UIs long ago and having worked on a CMS (Content Management System) for the past 5 years that is used to build very large company sites I believe I have a bit of knowledge on such attempts... And that is that UI presentations are never sufficient enough to do everything that knowledgeable individuals want to do.
-
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?? :-)
dandy72 wrote:
Who gets excited about TFS??
I don't get excited about any tool. Just as I don't get excited when I decide whether to use a hammer, saw or screw driver. I do know that git, and this is by design, only does versioning(labeling) at the repo level. That is entirely appropriate for a tool that was designed for open source libraries. But in a company enterprise system the ability to version (label) within a sub-code tree without managing subsystems as independent deliverables is something that can be very useful for large complex systems. This is appropriate for mid-size companies where they have gotten big enough that there is now more than one team but not many. When a company gets big enough of course they will start need to actively managing multiple deliverables including libraries. (It can be interesting to read what google uses for source control and git is not it.)
-
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.
-
dandy72 wrote:
acknowledge that this is entirely because I don't know it well enough
My peeve is when people are full of fluff. If you like TFS just because you like it and that's the only reason why... you do you. :laugh: It's when peeps start lying about another product they know little about as the justification, that's just no bueno.
dandy72 wrote:
Who gets excited about TFS??
:laugh: :laugh:
Jeremy Falcon
Jeremy Falcon wrote:
It's when peeps start lying about another product they know little about as the justification, that's just no bueno.
This. So much this. In the case of Git vs TFS, like I said, I stick with TFS because it's all I'm comfortable with (right now) and I haven't had any real bad experiences with it. I managed to get myself in trouble with Git in the past (my own ignorance / my own fault), and fortunately I had people who helped me out, but I still have zero problem saying Git is the way to go. I just wish I had the time and motivation to learn it, and learn it well, from a good, up to date, and reliable source.
-
dandy72 wrote:
Who gets excited about TFS??
I don't get excited about any tool. Just as I don't get excited when I decide whether to use a hammer, saw or screw driver. I do know that git, and this is by design, only does versioning(labeling) at the repo level. That is entirely appropriate for a tool that was designed for open source libraries. But in a company enterprise system the ability to version (label) within a sub-code tree without managing subsystems as independent deliverables is something that can be very useful for large complex systems. This is appropriate for mid-size companies where they have gotten big enough that there is now more than one team but not many. When a company gets big enough of course they will start need to actively managing multiple deliverables including libraries. (It can be interesting to read what google uses for source control and git is not it.)
jschell wrote:
I don't get excited about any tool. Just as I don't get excited when I decide whether to use a hammer, saw or screw driver.
Hypothetical situation: I suppose if you repeatedly have really bad, frustrating experiences with one tool, and have to put up with it for long periods of time (because there's just nothing better out there), then you find out about some other tool, give it a try, and it works a lot better - and you never go through a bad experience ever again - that'd be reason enough to get excited about something. I'm not saying this is what happened with my coworker, but I had to smile at his enthusiasm using a software program. You don't see that often. Bless him for that, I say.
-
Jeremy Falcon wrote:
It's when peeps start lying about another product they know little about as the justification, that's just no bueno.
This. So much this. In the case of Git vs TFS, like I said, I stick with TFS because it's all I'm comfortable with (right now) and I haven't had any real bad experiences with it. I managed to get myself in trouble with Git in the past (my own ignorance / my own fault), and fortunately I had people who helped me out, but I still have zero problem saying Git is the way to go. I just wish I had the time and motivation to learn it, and learn it well, from a good, up to date, and reliable source.
dandy72 wrote:
I managed to get myself in trouble with Git in the past
I'll admit, Git does have a higher learning curve. That's both good and bad ya know. There are things I can pull off with Git that would be impossible in other SCMs - I think. I know Git the best these days. What I do know for sure is that I can do just about anything one can imagine, but that comes at a cost of a learning curve. Anywho, if you don't have a pressing need for it and you do have something that works, that's a totally acceptable stance. I say that all the time about tech. Time is finite. There's other things life... like going outside... that are important too.
dandy72 wrote:
I just wish I had the time and motivation to learn it, and learn it well, from a good, up to date, and reliable source.
Yeah, unfortunately, the best reliable source is other developers actively using it IMO. And even that's not a perfect scenario, but that's how I learned it. Git books never really did it for me.
Jeremy Falcon
-
PIEBALDconsult wrote:
Labels. Git doesn't have them at all and they are critical.
They're called tags in git. Seriously man, we're supposed to be better than this.
PIEBALDconsult wrote:
And integrated ticketing.
I'm guessing you don't use any non-MS product? I'm sure there are tons of other products that do but Jira, as one example, has integrated with Git for years now. I mean years.
Jeremy Falcon
Jeremy Falcon wrote:
They're called tags in git.
No, those are a totally different thing. And I see no purpose for them. From what I see (RTFM), a Tag in Git (or Subversion) includes a version of all of the items in a repository. That's not what a Label in TFS (or a Class in CMS) is. With a Label or Class, you include only the items you are interested in -- which could be all of them, but usually not. Git should add this feature, it shouldn't difficult, and it will make things so much easier.
-
MSBassSinger wrote:
back in the 1990s created a very useful GUI builder for Visual Basic
Having worked on a system that specifically was intended to build UIs long ago and having worked on a CMS (Content Management System) for the past 5 years that is used to build very large company sites I believe I have a bit of knowledge on such attempts... And that is that UI presentations are never sufficient enough to do everything that knowledgeable individuals want to do.
And yet the WinForms GUI builder was so successful that other companies (like PowerBuilder) tried to copy it. It has successfully made Windows apps, including complex ones, to this day. It isn’t that it can’t be done - it has already. It is that it has not been tried with a team capable of the same level of quality and excellence as Alan Cooper and his team had.
-
Jeremy Falcon wrote:
They're called tags in git.
No, those are a totally different thing. And I see no purpose for them. From what I see (RTFM), a Tag in Git (or Subversion) includes a version of all of the items in a repository. That's not what a Label in TFS (or a Class in CMS) is. With a Label or Class, you include only the items you are interested in -- which could be all of them, but usually not. Git should add this feature, it shouldn't difficult, and it will make things so much easier.
How so? Isn't the purpose of a label to find a specific commit? To quote Microsoft:
Team Foundation Version Control (TFVC) labels provide a way for you to take a snapshot of your files. Later, you can refer back to that snapshot. By using your label, you can view, build, or even roll back a large set of files to the state they were in when you applied the label.
I realize you can name labels in TFS. You can also name tags in Git. So, how is it not the same thing?
Jeremy Falcon
-
Jeremy Falcon wrote:
They're called tags in git.
No, those are a totally different thing. And I see no purpose for them. From what I see (RTFM), a Tag in Git (or Subversion) includes a version of all of the items in a repository. That's not what a Label in TFS (or a Class in CMS) is. With a Label or Class, you include only the items you are interested in -- which could be all of them, but usually not. Git should add this feature, it shouldn't difficult, and it will make things so much easier.
PIEBALDconsult wrote:
With a Label or Class, you include only the items you are interested in -- which could be all of them, but usually not.
If you define files you're only interested in as files that changed for a commit, my understanding is that is a changeset. Keep in mind I haven't used TFS in years, so my memory is rusty. What non-Git peeps don't get is that Git doesn't need that feature. Git was designed from the ground up to be great a diffing, merging, etc. I've never seen another SCM do it better. If I need to figure out which files changed between commits, tags, or branches it's just one simple command away. So, Git can already do this.
Jeremy Falcon
-
How so? Isn't the purpose of a label to find a specific commit? To quote Microsoft:
Team Foundation Version Control (TFVC) labels provide a way for you to take a snapshot of your files. Later, you can refer back to that snapshot. By using your label, you can view, build, or even roll back a large set of files to the state they were in when you applied the label.
I realize you can name labels in TFS. You can also name tags in Git. So, how is it not the same thing?
Jeremy Falcon
As I said, a Label typically contains only a small subset of the items in the repository. Edit: That quote from MS is just a very brief overview of what Labels can be used for. It basically says nothing about what Labels are and the broad range of what they can be used for. If a Git user finds himself using TFS and wants to know how to make the equivalent of a Tag, the answer is a Label, but that doesn't mean that Labels and Tags are the same thing, they are not. They are not equivalent; Labels are greater than Tags. Find the actual documentation for Labels and read it.
-
As I said, a Label typically contains only a small subset of the items in the repository. Edit: That quote from MS is just a very brief overview of what Labels can be used for. It basically says nothing about what Labels are and the broad range of what they can be used for. If a Git user finds himself using TFS and wants to know how to make the equivalent of a Tag, the answer is a Label, but that doesn't mean that Labels and Tags are the same thing, they are not. They are not equivalent; Labels are greater than Tags. Find the actual documentation for Labels and read it.
Ok, so if it's backwards... then as I said Git already does that. You still didn't define what constitutes a subset btw. So, let's just assume it's a diff of files that changed between commits. Git does this. Saying it doesn't isn't correct.
Jeremy Falcon
-
PIEBALDconsult wrote:
With a Label or Class, you include only the items you are interested in -- which could be all of them, but usually not.
If you define files you're only interested in as files that changed for a commit, my understanding is that is a changeset. Keep in mind I haven't used TFS in years, so my memory is rusty. What non-Git peeps don't get is that Git doesn't need that feature. Git was designed from the ground up to be great a diffing, merging, etc. I've never seen another SCM do it better. If I need to figure out which files changed between commits, tags, or branches it's just one simple command away. So, Git can already do this.
Jeremy Falcon
I suspect you never used Labels in TFS either, many people don't.
Jeremy Falcon wrote:
If you define files you're only interested in as files that changed for a commit,
Certainly, but... A Changeset may contain items which are not to be deployed. A Label can contain versions of items from multiple Changesets.
Jeremy Falcon wrote:
Git doesn't need that feature
Yes, yes it does. And I suspect they can alter Tags so they do it.
Jeremy Falcon wrote:
If I need to figure out which files changed between commits, tags, or branches it's just one simple command away. So, Git can already do this.
That's not what Labels are for, and TFS can do that as well of course.
-
Ok, so if it's backwards... then as I said Git already does that. You still didn't define what constitutes a subset btw. So, let's just assume it's a diff of files that changed between commits. Git does this. Saying it doesn't isn't correct.
Jeremy Falcon
Jeremy Falcon wrote:
it's a diff of files that changed between commits
No. That is not what a Label/Class is. That may be a typical use for a Label, but I can put any version of any item in the repository in a Label any time I want. An item/element doesn't need to have changed to be put in a Label/Class.
-
I suspect you never used Labels in TFS either, many people don't.
Jeremy Falcon wrote:
If you define files you're only interested in as files that changed for a commit,
Certainly, but... A Changeset may contain items which are not to be deployed. A Label can contain versions of items from multiple Changesets.
Jeremy Falcon wrote:
Git doesn't need that feature
Yes, yes it does. And I suspect they can alter Tags so they do it.
Jeremy Falcon wrote:
If I need to figure out which files changed between commits, tags, or branches it's just one simple command away. So, Git can already do this.
That's not what Labels are for, and TFS can do that as well of course.
PIEBALDconsult wrote:
That's not what Labels are for, and TFS can do that as well of course.
Given this video (it's 2 minutes only), either this dude is wrong or labels are meant to tag a specific set of files, as well the MS link suggested... [TFS 2013 Tutorial : 24 - How to Apply Labels in Team Foundation Server 2013 using visual Studio - YouTube](https://www.youtube.com/watch?v=zRVLQWrj2AM) You can modify tags in git and labels in TFS so I'm not sure why bringing this up is relevant. If you need to stage files not marked for release that are in your repo for some reason, let's say internal documentation, that can be achieved with git 100%. However, that's a bad design to do that in the SCM itself. Anything exclusionary should be a part of the build process. So, to keep this on point... right now, I'm mentally considering a changeset like a commit in Git terms. Given that, if for some reason you need a label of two different changesets that are completely unrelated (history-wise) to one another in a label, again Git doesn't work that way. Nor should it. That's just a bad design. If you need that, then merge or rebase into whatever branch you're working on in question and create a tag off that. You'll have exactly the same thing but with a consolidated history trail. Git is more analogous to the blockchain in terms of a history trail. That's a good thing. Also, if labels aren't used to tag a release, why are people saying it is?
Jeremy Falcon
-
I suspect you never used Labels in TFS either, many people don't.
Jeremy Falcon wrote:
If you define files you're only interested in as files that changed for a commit,
Certainly, but... A Changeset may contain items which are not to be deployed. A Label can contain versions of items from multiple Changesets.
Jeremy Falcon wrote:
Git doesn't need that feature
Yes, yes it does. And I suspect they can alter Tags so they do it.
Jeremy Falcon wrote:
If I need to figure out which files changed between commits, tags, or branches it's just one simple command away. So, Git can already do this.
That's not what Labels are for, and TFS can do that as well of course.
Btw, I have used labels in the past, but that was like well over a decade ago. Seems like forever and I totally accept my memory is fuzzy in that regards, so I could be going senile. :laugh:
Jeremy Falcon
-
I guess Word documents would have that problem too then. But using version control for Word docs has always been problematic. I remember people trying to track changes using Visual Source Safe back in 1996
Yes, but Visual SourceSafe had an option to store only the most recent version of a binary file, which was a great feature.
