|
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'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: but I do long for the days of locking a file so no one else could modify while I was
Or, another way to say this..."I hate merging!" right? 
We all hate merge conflicts!! 
|
|
|
|
|
Not everything can be merged...SSIS for example.
|
|
|
|
|
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.
|
|
|
|
|
Since VCS (Verson Control Systems) are meant to store diffs between files...
what would the point of storing?...
DavidPendleton wrote: only the most recent version of a binary file
Isn't that the same as storing the latest binary file which is already simply stored in the file system?
I'm curious about this. thanks
|
|
|
|
|
We used it for daily builds of DLL's and the like. It gave us a way to keep binaries with the code without taking up a lot of space in the VSS database. You could check it out to keep it from being overwritten when you needed that.
It also allowed us (the developers) to manage the folder structure, security, etc. instead of the network folks. Other than that, it was pretty-much the same as a network folder.
|
|
|
|
|
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
modified 1-Nov-23 13:15pm.
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
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.
modified 3-Nov-23 10:19am.
|
|
|
|
|
It seems MS itself is abandoning TFVC (or whatever name they give it this week) in favor of git, internally, or at least that's the impression I got back when I was working for someone who had a contract with them.
Is someone actually moving from git to TFVC, or have you changed companies, and the new one simply has never used git before and you're comparing your experiences?
|
|
|
|
|
New company.
I know they already have some products on git.
Moving to git is in the plan.
CI/CD = Continuous Impediment/Continuous Despair
|
|
|
|
|
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
|
|
|
|
|
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...
|
|
|
|
|
True. Sadly, the "power of git" slows me down. 
/ravi
|
|
|
|
|
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.
|
|
|
|
|
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"? 
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.
|
|
|
|
|
PIEBALDconsult wrote: The Git integration in Visual Studio is much weaker than TFS'. I hope they improve it.
There's hardly anywhere else to go, IMO. 
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
