We don't understand TFS and we don't want to.
-
@lucas1 said in We don't understand TFS and we don't want to.:
If you are trying to build something complicated your tooling and circumstances won't be simple and one tool won't fit al
RECAP on my position:
- I don't believe there is any universally best [anything]
- I don't believe there is any universally worst either
- Some efforts (such as global management of Lunix Distros) are great matches for Git [I would not recommend attempting it with any other tool.
With that fresh in memory. I will dispute the above quote. There is one (Set of) systems I work with that involves everything from COBOL (Univac mainframe) to IOT, with client, server, mobile, and others in between.
A single tool handles it all quite well, and that tool is TFS - with a single TFVC repository.
-
@thecpuwizard said in We don't understand TFS and we don't want to.:
A single tool handles it all quite well, and that tool is TFS - with a single TFVC repository.
And I disagree because of my previous experience of working with about 100 of dev some off shore, some in the office but a 5 minute walk across the office (they were that large).
That is fine btw. I get you are used to working like you are. I don't think it is as efficient as you think it is, and I just think most of the complaints aren't that important IMO.
We disagree on it. That is fine. I don't think I will convince you and I think the opposite is true.
I am not that bothered, because we obviously have different use cases.
The whole point of this thread was that I was just blowing off some steam about my current team using TFS badly. I don't hate TFS I think it is pretty good. I prefer git, but I took the job knowing I would be using a tool that I thought wasn't as good IMHO. I am not that precious about tooling. If everyone wants to use tool X in the team, I use Tool X.
I dunno what else to say.
-
@lucas1 - I have no problem with that. it is when anyone (so this is not directly at you per se) makes a claim that X is universally better (or worse) than Y that I have a problem.
Different situations determine what is the most effective [you used the word efficient, and I do suggest you do some research on the difference, and why efficiency can actually be the death of an organization due to a lack of effectiveness].
FWIW: 100 devs is not that large. Some organizations I work with have thousands, and occasionally (Rarely) break the 10K barrier.
-
@thecpuwizard I totally agree. I was cockier earlier on in my career but I don't pretend to know everything because I know as you know more you know how much you don't know.
-
@lucas1 said in We don't understand TFS and we don't want to.:
I am not a game developer but I suspect their tooling is much more complicated than what I use.
Here's our tooling steps:
- Get Latest from the local source control server (in this case, Perforce)
- Call Setup.bat (once, which does actually do what appears to be a
git checkout. But this is done once and the actual.gitstuff isn't stored, nor is it actually using an actual full git client but some wanky thing Epic programmed) - Call GenerateProjectFiles.bat (which essentially scans the source directories for .h and .cpp files and makes .sln files for Visual Studio)
- Some shenanigans with other batch files which ensure the UnrealBuildTool is correct and up to date.
- Call UnrealBuildTool, which essentially calls the visual studio solution build process (I don't remember what the tool itself was called) and runs the UE4 Editor to "cook" the assets and "package" them into what amounts to a zip file.
Total version control systems required? One and an invisible second one that you don't even need to know or worry about because nobody in the house interacts with it in any way.
-
@lucas1 said in We don't understand TFS and we don't want to.:
@thecpuwizard I totally agree. I was cockier earlier on in my career but I don't pretend to know everything because I know as you know more you know how much you don't know.
This almost makes sense....
-
@tsaukpaetra ERR Perforce ... right mate ... I am running away. I don't want hydra to catch me :)
-
@dkf said in We don't understand TFS and we don't want to.:
With a distributed version control system, everyone is always on a different branch.
The idiot developers of Git chose that design, I say for the 47th time in this thread. It's not some Divine Law Of God that Git work that way; they chose to code it in such a way that useful features are impossible to implement.
You Git fans act like Moses delivered Git to you on 2 giant stone tablets. Christ. Human beings made the decision to make Git shitty.
@dkf said in We don't understand TFS and we don't want to.:
Locking is technically unnecessary in such a scenario;
Of course it's not "necessary". Who said it was? But there's a hell of a lot of cases where it's super-useful and saves people from wasting their time.
@dkf said in We don't understand TFS and we don't want to.:
While you continue to assert (incorrectly) that there's really a single shared state, you'll continue to assert (incorrectly) that locking is necessary.
I never once asserted that locking was necessary. Quote me. I fucking dare you. I fucking double dog dare you.
How come every debate I get into on this forum turns into people debating against things I never even said? Are y'all just fucking retarded? I'm gonna go with that.
@dkf said in We don't understand TFS and we don't want to.:
You'll also think (incorrectly) that branches are expensive things to be hoarded carefully,
I also never said this, for the record.
@dkf said in We don't understand TFS and we don't want to.:
It's all a mark of that basic mental model not matching the reality of systems in different places not actually being magically synchronised with each other.
TFS doesn't use magic to keep things in sync, it uses TCP/IP and SQL Server.
@lucas1 said in We don't understand TFS and we don't want to.:
These assets don't change all that often in reality.
As I stated above, the point is that TFS has an answer for when they do. Where Git is just completely useless in this situation.
@lucas1 said in We don't understand TFS and we don't want to.:
If the are that many binary files, git can't delta them anyway and then repo could become very large. It is a valid complaint and then maybe Git isn't the tool for you.
Correct; and yet your employer is going to make using it a condition of employment anyway because Git (inexplicably) has so goddamned many cheerleaders in this industry. Despite sucking.
-
@lucas1 said in We don't understand TFS and we don't want to.:
@tsaukpaetra ERR Perforce ... right mate ... I am running away. I don't want hydra to catch me :)
It's.... sufficient.
And that's all I'll say about that. :P
-
@tsaukpaetra Kinda off topic:
They are making me do more backend stuff at the company and I just struggle when it comes to SQL / C# stuff tbh.
I can do it. But I been doing some much JS / CSS I am much happier doing that. They gave me loads of front end bugs on Friday and I just blasted through them whereas on my SQL / C# jobs I was always late. Everyone front end task I can do really easily and then I struggle when it comes to doing SQL mainly because it takes me probably several times longer than the rest of the team to write a query. I can do it ... just take me a while longer.
Maybe it is a self fulfilling prophecy.
-
@blakeyrat said in We don't understand TFS and we don't want to.:
TFS doesn't use magic to keep things in sync, it uses TCP/IP and SQL Server.
No TFS uses Http .... FFS get your propaganda right.
The TFS default port is 8080 and so is the web interface. You are just a fucking total MONG aren't you?
-
@lucas1 said in We don't understand TFS and we don't want to.:
No TFS uses Http .... FFS get your propaganda right.
Oh right. I forgot for a moment HTTP only runs over AppleTalk. Silly me.
-
@blakeyrat You are trying to make out that you were right when you were wrong ... nice try. Stop being a mongoloid.
-
@lucas1 said in We don't understand TFS and we don't want to.:
@tsaukpaetra Kinda off topic:
They are making me do more backend stuff at the company and I just struggle when it comes to SQL / C# stuff tbh.
I can do it. But I been doing some much JS / CSS I am much happier doing that. They gave me loads of front end bugs on Friday and I just blasted through them whereas on my SQL / C# jobs I was always late.
Maybe it is a self fulfilling prophecy.
I'm only just above average with JS and HTML, and less so with CSS, but that's my current task with the voting thing.
It's also PHP with MySQL on the backend, but overall it's a tiny backend, but still...My C# is better but since most of the stuff I'm working on doesn't use it I use it as the breath of fresh air after sucking around in UE4's brand of C++...
-
@lucas1 said in We don't understand TFS and we don't want to.:
@blakeyrat said in We don't understand TFS and we don't want to.:
TFS doesn't use magic to keep things in sync, it uses TCP/IP and SQL Server.
No TFS uses Http .... FFS get your propaganda right.
The TFS default port is 8080 and so is the web interface. You are just a fucking total MONG aren't you?
Actually Blakey is more correct. While TFS does use HTTP/HTPS for most things, other TCP/IP protocols are in use.
-
@tsaukpaetra Personally as a more front end dev, I think all this strong binding that MVC 3 upwards does is too much and you kinda sometimes just want to rip out the form post values, and then just validate them yourself.
-
@lucas1 said in We don't understand TFS and we don't want to.:
@tsaukpaetra Personally as a more front end dev, I think all this strong binding that MVC 3 upwards does is too much and you kinda sometimes just want to rip out the form post values, and then just validate them yourself.
Yeah, my MVC things end up not being very MVC-like at all, I've found...
-
@thecpuwizard said in We don't understand TFS and we don't want to.:
Actually Blakey is more correct. While TFS does use HTTP/HTPS for most things, other TCP/IP protocols are in use.
There's also the whole bit about how HTTP runs over TCP/IP. So let's just mark that on the chalkboard as Blakeyrat being double-correct.
-
@thecpuwizard For the most part it is HTTP. I just. TBH I wanted to have another chance to get in his face.
-
@blakeyrat Nope. It means you don't know as much as you claim you do. As it make you feel better I will give you another hugbox synthwave and a big kiss
https://www.youtube.com/watch?v=GNPKmXMephs
And I love you @blakeyrat lots of kisses
-
@tsaukpaetra This, I end up munging stuff into the database and back 4 different times because everything must be hidden behind 4 interfaces that are a "service".
-
@blakeyrat said in We don't understand TFS and we don't want to.:
The idiot developers of Git chose that design, I say for the 47th time in this thread. It's not some Divine Law Of God that Git work that way; they chose to code it in such a way that useful features are impossible to implement.
Since virtually nothing of what I wrote in that message was git-specific (and deliberately so) I conclude that you're either unable to parse language as used by humans even where the phrasing is exact, or you're so caught up in your own crusade that you're letting yourself be mislead on what other people are saying by your shoulder aliens.
It is the design of a DVCS (each and every last one of them) that branches are not shared. They can be cloned and replicated, but that's not the same thing. By giving up the sharing, they become able to stop worrying about locking (as locking always requires sharing; a lock isn't a lock unless everyone agrees you've got it) and instead focus on recording the history of (directory trees of) files. It's that history that is the main topic of discussion with a DVCS; focusing on the individual files in the “current” state is just fundamentally wrong and confusing.
All version control systems that I can think of support the concept of branching. Once you have branches, you properly need a different concept of “current” that is with respect to a particular branch. Once you have a DVCS, branches become things that are properly local to each participating computer, and “current” becomes even harder to justify (and locking becomes even less useful, since a lock on your branch doesn't justify a lock on anyone else's).
Now there are some downright weird bits to git (such as being able to have many different servers that have totally different concepts of what the history is) and it has capabilities that I find highly “yikes!” (like history rewriting) and its UI is plain old misanthropic, but your objections all sound like they're not based on any of the possible sane criticisms. They all come across as “it's not following my own exact mental model of a shared drive, so IT'S TOTAL SHIT!” and that's just an unintelligent type of argument. I dislike git, but I at least understand it. You don't even do that.
-
@dkf said in We don't understand TFS and we don't want to.:
Since virtually nothing of what I wrote in that message was git-specific (and deliberately so) I conclude that you're either unable to parse language as used by humans even where the phrasing is exact, or you're so caught up in your own crusade that you're letting yourself be mislead on what other people are saying by your shoulder aliens.
Ok.
@dkf said in We don't understand TFS and we don't want to.:
It is the design of a DVCS (each and every last one of them) that branches are not shared.
Right. But that design was created by a human being, and could be changed to a more useful design if the designer gave a shit about the quality of their product.
@dkf said in We don't understand TFS and we don't want to.:
By giving up the sharing, they become able to stop worrying about locking (as locking always requires sharing; a lock isn't a lock unless everyone agrees you've got it) and instead focus on recording the history of (directory trees of) files.
But they also lack the ability to do optional locking. Which is a useful feature. Because they refuse to change the design to a more useful one. Like, for example, the one TFS uses. Which allows working offline and optional file-locking, as is by magic!
@dkf said in We don't understand TFS and we don't want to.:
It's that history that is the main topic of discussion with a DVCS; focusing on the individual files in the “current” state is just fundamentally wrong and confusing.
Not even sure how this is relevant to anything.
@dkf said in We don't understand TFS and we don't want to.:
All version control systems that I can think of support the concept of branching. Once you have branches, you properly need a different concept of “current” that is with respect to a particular branch. Once you have a DVCS, branches become things that are properly local to each participating computer, and “current” becomes even harder to justify (and locking becomes even less useful, since a lock on your branch doesn't justify a lock on anyone else's).
Ok...
You've totally lost me. What are you even talking about at this point?
Also you don't even slightly seem to be getting my point here.
Sure, all current DVCS systems work this way. Fine. But my point is: it's not God's Own Divine Law that they work this way! Do you understand that human beings made Git the way it is, and that if they wanted, they could change it so it supported things like optional file locking? Do you get it? At all? Because I still don't think you do.
Look. My car had a faulty airbag. Here's your post, but with my car:
Well you see, auto manufacturers use airbags from a company called Takata, and these airbags are prone to sometimes fail to deploy correctly in an accident. All cars with Takata airbags have this problem, so if you own one of those cars your airbag might fail to deploy correctly.
See what you're missing? You're missing;
- The acknowledgement that choosing Takata brand airbags was a choice someone made, and therefore it may have been a bad choice.
- The acknowledgement that Takata airbags could ever be made to work more reliably.
You're plopping yourself into this thread and saying "Git doesn't support optional locking because of a choice Git made that is 100% Git's decision to make and there's literally no other choice they could possibly have made my tiny brain is closed to all outside thought forever."
Do. You. Understand. What. I. Am. Trying. To. Get. Across. Here.
It's infuriating how my words are just bouncing off your skull.
No, it's not God's Own Commandment that distributed source control systems suck. Sucking is a decision the developers of Git made. Ok? Do you get it? Do. You. Get. It.
-
@blakeyrat said in We don't understand TFS and we don't want to.:
Right. But that design was created by a human being, and could be changed to a more useful design if the designer gave a shit about the quality of their product.
But had a different decision been made, then the result would not have been a distributed system. There would have been centralization. Perhaps the a decision to be Tofu Farmers rather than writing a SCM system would have been beneficial.
But (to me) the question remains, is maximum effectiveness for projects which are centralized in nature [i.e. to make a profit for a specific entity] best served by a system designed to let some unknown developer in the most remote place on the planet make a change to an obscure utility in Linux have a path whereby that change can be (though very unlikely ever to be) propagated to every other developer on the planet who might want to make use of that change?
-
@thecpuwizard said in We don't understand TFS and we don't want to.:
But had a different decision been made, then the result would not have been a distributed system. There would have been centralization.
So?
Look, I don't want fucking philosophy in my software, I want features. I'm sorry TFS is not as "pure" for you ivory tower dumbshits, or whatever the fuck you think is so wrong about having a goddamned server.
-
@blakeyrat said in We don't understand TFS and we don't want to.:
@thecpuwizard said in We don't understand TFS and we don't want to.:
But had a different decision been made, then the result would not have been a distributed system. There would have been centralization.
So?
Look, I don't want fucking philosophy in my software, I want features. I'm sorry TFS is not as "pure" for you ivory tower dumbshits, or whatever the fuck you think is so wrong about having a goddamned server.
Hmm.. I am a (strong) advocate for TFS and typically recommend against Git for most "corporate" type projects, so I am not sure where that comment came from..
-
@thecpuwizard Just anticipating replies from the other morons on this thread, who you know are just itching to type "but a fully distributed design is more PURE and HOLY!"
-
-
@greybeard said in We don't understand TFS and we don't want to.:
It's been answered several times. It's a common English verb. Do I need to give you a lmgtfy url to the dictionary definition?
It's only any good for native speakers, though. Which is why you shouldn't use idioms in your software, if usability is a concern. And it always is. Unless the software is git.
-
@blakeyrat said in We don't understand TFS and we don't want to.:
@thecpuwizard Just anticipating replies from the other morons on this thread, who you know are just itching to type "but a fully distributed design is more PURE and HOLY!"
Or... The features that many people want are different than the ones that you want.
-
@magus said in We don't understand TFS and we don't want to.:
@greybeard said in We don't understand TFS and we don't want to.:
It's been answered several times. It's a common English verb. Do I need to give you a lmgtfy url to the dictionary definition?
It's only any good for native speakers, though. Which is why you shouldn't use idioms in your software, if usability is a concern. And it always is. Unless the software is git.
Why are you still going on with this nonsense? Practically everything we use to talk about computing is metaphorical. They're all abstractions. Including your beloved "check in."
-
@boomzilla said in We don't understand TFS and we don't want to.:
Or... The features that many people want are different than the ones that you want.
That's fine.
Git is still shitty because of its godawful usability and accessibility, but if you're happy with the features it offers, so be it. I'm not.
-
@blakeyrat said in We don't understand TFS and we don't want to.:
@boomzilla said in We don't understand TFS and we don't want to.:
Or... The features that many people want are different than the ones that you want.
That's fine.
Git is still shitty because of its godawful usability and accessibility, but if you're happy with the features it offers, so be it. I'm not.
I never said I was. Though in this particular case (distributed system vs file locking) I am of quite the opposite opinion as you.
-
@boomzilla At least you seem to understand the basic concept that Git chose the design they use and it wasn't dictated to them. Which apparently a lot of other people believe, for some reason I'll never comprehend.
-
@boomzilla There are different kinds of abstractions. Using simple, normal words that everyone knows is always better. I know what cherry picking is, and how that makes sense in context, but why abstract it if you don't have to? Why not just use simple words? What advantage does the abstraction have here? This is on a different level from jargon: this is an idiom. Why use idioms in software?
-
@magus said in We don't understand TFS and we don't want to.:
Using simple, normal words that everyone knows is always better.
I agree, assuming such exist.
-
@boomzilla I think something like "pull selective commits" might be valid for this. Unless I have an incomplete understanding of git jargon, which is probably true. I don't have time to read the entire site that explains the manual.
-
@magus said in We don't understand TFS and we don't want to.:
@boomzilla I think something like "pull selective commits" might be valid for this. Unless I have an incomplete understanding of git jargon, which is probably true. I don't have time to read the entire site that explains the manual.
It would be "merge selected commits," if anything.
-
@blakeyrat so central repo works great when you have like 10 devs. When you have hundreds, it does not scale well.
For some reason you think that there is a optimum solution for every situation. There isn't.
If you think TFS / SVN is better for a project ... FUCKING USE IT.
If you think Git or similar is better ... FUCKING USE THAT.
At the end of the day you are complaining the Mallet isn't as good as hammering Nails as the Hammer.
-
@lucas1 Right; that explains why they never used TFS on big projects like MS Word, SQL Server or Windows.
And why Microsoft was able to make Git suitable for use with Windows without making any changes to it at all.
-
@blakeyrat Because I suspect they weren't using the same version as the customers got. Also they have moved over to Git.
Microsoft have a fucking huge Git repo for Windows.
-
@lucas1 said in We don't understand TFS and we don't want to.:
Microsoft have a fucking huge Git repo for Windows.
But they had to do a big old rewrite to make it suitable for a project of that size
-
@jaloopa They made a filesystem or something. I don't know. TBH, this thread was about me shitting on my company for basically using TFS like retards.
-
@lucas1 said in We don't understand TFS and we don't want to.:
so central repo works great when you have like 10 devs. When you have hundreds, it does not scale well.
Not true. It works great here.
@lucas1 said in We don't understand TFS and we don't want to.:
For some reason you think that there is a optimum solution for every situation. There isn't.
He doesn't. He just thinks there are things better than git. He's clearly said they aren't optimal.
@lucas1 said in We don't understand TFS and we don't want to.:
If you think TFS / SVN is better for a project ... FUCKING USE IT.
If you think Git or similar is better ... FUCKING USE THAT.He, and I also, wish that was an option. But idiots force git on every project ever these days.
-
@magus said in We don't understand TFS and we don't want to.:
He doesn't. He just thinks there are things better than git. He's clearly said they aren't optimal.
Maybe I didn't notice that with the constant rants, insults and refusing to understand someone else. I can have 10 pints of beer and not as be bad as this guy.
-
@magus said in We don't understand TFS and we don't want to.:
He, and I also, wish that was an option. But idiots force git on every project ever these days.
No they don't.
Then again you are the person who claimed that numbers wasn't an indicator of quality because you could make a bad example and ignore me when I made the counter counter example of a good thing that was used by the masses.
So I know you can't be objective.
-
@lucas1 said in We don't understand TFS and we don't want to.:
Then again you are the person who claimed that numbers wasn't an indicator of quality
It isn't.
@lucas1 said in We don't understand TFS and we don't want to.:
because you could make a bad example and ignore me when I made the counter counter example of a good thing that was used by the masses.
Any example of anything that is popular but not good simply means that popularity has very little meaning. There are good and bad popular things.
@lucas1 said in We don't understand TFS and we don't want to.:
No they don't.
I'm telling you that I am working on a project where the choice wasn't in my hands. Like most people. A 100% centralized project, with only around 10 devs. It cannot be more true that you are wrong right now.
-
@lucas1 And as far as I can tell, that's frequently what happens.
-
@magus said in We don't understand TFS and we don't want to.:
Any example of anything that is popular but not good simply means that popularity has very little meaning. There are good and bad popular things.
Typically if something sells well it is of good enough quality for people to want to buy it in mass. That is the definition of a good product from a business perspective.
So numbers can be an indicator of quality. Just because you are being a snob, doesn't mean that it isn't good enough for the rest of us.
Also as I previously try to tell you the market will allow more prestige products for snobs such as yourself.
-
@lucas1 said in We don't understand TFS and we don't want to.:
Because I suspect they weren't using the same version as the customers got.
Right; the only solution to this conundrum is conspiracy theories.
@lucas1 said in We don't understand TFS and we don't want to.:
Also they have moved over to Git.
After spending years fixing Git so it was suitable for the job.
@lucas1 said in We don't understand TFS and we don't want to.:
Microsoft have a fucking huge Git repo for Windows.
Yeah my post was sarcasm, numbnuts.
