We don't understand TFS and we don't want to.
-
@magus said in We don't understand TFS and we don't want to.:
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.
I am working in a project where I didn't have a choice in source control. I've complained on here how they have used it badly. But I have a job and I am getting the job done.
TFS wasn't forced on me, just everyone else was using it before.
Oh noes the horror.
-
@blakeyrat Microsoft wouldn't have invested all that time in it if they didn't think it was worth the effort.
Why don't you ask Microsoft? I am sure they can tell you why better.
-
@blakeyrat said in We don't understand TFS and we don't want to.:
Yeah my post was sarcasm, numbnuts.
Here is another cool tune to relax:
https://www.youtube.com/watch?v=nphbscKYZV0
Also another kiss of love from me:
Here is a little poem to go along with it:
As you can see
Two pigeons together
Not lost in the sea
They might be white
But they aren't alt-right
There is no fight
Even though each one thinks he has the right.
-
@blakeyrat said in 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.:
Because I suspect they weren't using the same version as the customers got.
Right; the only solution to this conundrum is conspiracy theories.
Knowing that Blakey is likely to blast me for "name dropping"... I work closely with the Microsoft Product Group (NOT employed by Microsoft, and frequently a vocal critic of them)...
You are right, they are not using the same version as the customers get. They are ahead of the curve, "dogfooding" the software before it is released to external customers. About 60K developers. By the time a "Normal" (i.e. not insider or fast-ring, or other specialized adopters) get it, that version (yes, the exact binaries) have been extensively used.
-
@thecpuwizard So you are saying I was right ... brilliant.
-
@lucas1 said in We don't understand TFS and we don't want to.:
@thecpuwizard So you are saying I was right ... brilliant.
That totally went over your head didn't it...... Every version of the software (TFS/VSTS) that a customer gets is software that has had significant use by Microsoft Teams. Your implication was that Microsoft is using some type of "special version" which is 100% false.
-
@thecpuwizard Err the cutting edge version can be considered non-normative and indeed a bit unique and thus special. You guys bring the fire and when someone tries to burn you back you get all fucking uppity.
As I implied correctly, they were using versions that weren't available to the rest of the TFS community internally, therefore I am correct. You have confirmed this by your own words.
-
@lucas1 said in We don't understand TFS and we don't want to.:
I am working in a project where I didn't have a choice in source control. I've complained on here how they have used it badly. But I have a job and I am getting the job done.
TFS wasn't forced on me, just everyone else was using it before.
Oh noes the horror.When you tell me to "JUST CHOOSE IT" and I tell you I don't have the ability, and then you respond like this, how can anyone ever consider talking to you as productive?
-
@lucas1 said in We don't understand TFS and we don't want to.:
@thecpuwizard Err the cutting edge version can be considered non-normative and indeed a bit unique and thus special. You guys bring the fire and when someone tries to burn you back you get all fucking uppity.
As I implied correctly, they were using versions that weren't available to the rest of the TFS community internally, therefore I am correct
AT THAT MOMENT IN TIME!!!!! For example Build 12.0.40639.0 was release on July 20, 2015. It was used as the primary software at Microsoft 3 months before that. By the time that happened, 14.0.23128.0 was already in production use (as had been 14.0.22604.0,14.0.22824.0,14.0.23102.0) all of which had been made available to the public between July 2015 and November 2015.
-
@magus When I decided to take the job, I knew they use TFS and I chose to work there knowing that they used it.
-
@thecpuwizard You are being a dick just to prove me wrong because you don't like me. You knew full well what I meant.
If you want to be that way. That is your choice. I was right and you confirmed it.
-
@lucas1 said in We don't understand TFS and we don't want to.:
@thecpuwizard You are being a dick just to prove me wrong because you don't like me. You knew full well what I meant.
If you want to be that way. That is your choice. I was right and you confirmed it.
I don't know you well enough to not like you.
Look at yor specific statement:
Because I suspect they weren't using the same version as the customers got.
The version(s) they were using are the exact same version(s) that the customer got.
-
@thecpuwizard Except the customers got it later. I didn't doubt that customers got the same improvement in the future.
I didn't think Microsoft was using the "Super Gay Space Communist version of TFS" internally. I just said they were using a better version that hadn't been released yet.
Sorry for the confusion.
-
@lucas1 said in We don't understand TFS and we don't want to.:
the "Super Gay Space Communist version of TFS"
If that has super-AIs spouting red-tinged rainbows, it sounds awesome!
-
@lucas1 said in We don't understand TFS and we don't want to.:
@magus When I decided to take the job, I knew they use TFS and I chose to work there knowing that they used it.
There is a point hidden in the incoherent rambling here. If I interview for a job, one of the questions I ask will be about what version control they use. If they use Git then I'm not taking the job unless everything else about the company is amazing or I'm desperate and literally nowhere else is offering me anything
-
@lucas1 said in We don't understand TFS and we don't want to.:
Except the customers got it later
That makes no sense given the original context. If they're getting new versions of TFS a few months before the public, that means that in the worst case, TFS was a few months off being able to support something the size of MS Word, SQL Server or Windows. And I don;t think any of them were developed in a matter of months
-
@lucas1 said in We don't understand TFS and we don't want to.:
You are being a dick just to prove me wrong because you don't like me. You knew full well what I meant.
It's called pedantic dickweedery and it has nothing to do with you. You are not special.
-
@jaloopa said in 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.:
@magus When I decided to take the job, I knew they use TFS and I chose to work there knowing that they used it.
There is a point hidden in the incoherent rambling here. If I interview for a job, one of the questions I ask will be about what version control they use. If they use Git then I'm not taking the job unless everything else about the company is amazing or I'm desperate and literally nowhere else is offering me anything
That seems like an excessive requirement.
I think the only source control system I'd do that with is Borland StarTeam that I used at my first job. And maybe other janky older ones like VSS and CVS.
Anything newer (not necessarily new), like Subversion, Mercurial, Git, TFS, etc, are probably not a problem.
-
@mikehurley I do that with email system (if they say Lotus Notes, I'm out), but I don't bother with source control because even if they say something other than Git, one of Git's brainwashed moron fans will convince them to migrate to Git soon.
At least Lotus Notes is bad but dying.
-
@lucas1 said in We don't understand TFS and we don't want to.:
Microsoft wouldn't have invested all that time in it if they didn't think it was worth the effort.
Just because people demand something (and it's marketed better) doesn't mean it is better. Look at VHS vs Beta.
-
@dcon Well this is the worse is better principle surely?
Dreaded car example, most of the cars in the UK are probably Ford Focuses and Vauxhall Astras. They aren't brilliant cars, but for the vast majority of people they are more than good enough.
-
@boomzilla said in We don't understand TFS and we don't want to.:
@blakeyrat ... Don't use a GUI client.
YMBNH.
-
Oh, speaking of, just dropping in, but Perforce decided to jump on the bandwagon too.
I'm almost tempted to join the webinar just to ask if they support exclusive checkouts on Git repos...
Edit: Oh, I just scrolled down. Apparently they magiced something and All The Builds are 80% Faster!
-
This post is deleted!
-
@tsaukpaetra A git server doesn't do builds? WAT?
-
@lucas1 said in We don't understand TFS and we don't want to.:
@tsaukpaetra A git server doesn't do builds? WAT?
I mean, correct me if I'm wrong, but a git server is basically a network file share...
-
@tsaukpaetra more like a SSH connection with some logic that runs on connect.
But build speed is based on the build agent that is running your build. Not how fast your connection to source control is.
-
@lucas1 said in We don't understand TFS and we don't want to.:
@tsaukpaetra more like a SSH connection with some logic that runs on connect.
But build speed is based on the build agent that is running your build. Not how fast your connection to source control is.
Retrieving the source can be a significant percentage of that time.
-
@thecpuwizard I used to work with a 6gb code base on TFS 2010. It took 20 minutes (this was a 4mbit/s tunnel).
Most places don't work with 6gb codebases. Maybe a few hundred at most. 100mbit/s has been a thing for a while now.
-
@thecpuwizard said in 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.:
@tsaukpaetra more like a SSH connection with some logic that runs on connect.
But build speed is based on the build agent that is running your build. Not how fast your connection to source control is.
Retrieving the source can be a significant percentage of that time.
True this. If we did clean builds of the game every time, it would take almost 40% of the (total 6 hours) build time. And that's at gigabit speeds...
-
@tsaukpaetra Surely you have that in the company network rather than outside. Most of the time I use cloud services.
-
@lucas1 said in We don't understand TFS and we don't want to.:
@tsaukpaetra Surely you have that in the company network rather than outside. Most of the time I use cloud services.
Yes, this is all in house. In particular, on the same switch.
-
@tsaukpaetra Damn, but you do work on video games rather than wanky web projects like me :)
-
@lucas1 said in We don't understand TFS and we don't want to.:
Most places don't work with 6gb codebases. Maybe a few hundred at most. 100mbit/s has been a thing for a while now
6GB is tiny for a TFVC repository :) I am currently doing an upgrade/migration on one that is nearly 3TB (granted this is never all mapped for a single build).
-
@lucas1 said in We don't understand TFS and we don't want to.:
@tsaukpaetra Damn, but you do work on video games rather than wanky web projects like me :)
Yes. A majority of the time is spent on <1kb files. Apparently no protocol on Earth can handle that efficiently...
Once it gets to the non-mergable files though it flies a bit faster. Though those tend to be 0.3Mb - 20Mb, so it's still not so fast.
-
@thecpuwizard Okay whatever mate, considering you and @blakeyrat have kept on making up reasons why Git is evil. I don't believe you. Sorry.
-
@lucas1 said in We don't understand TFS and we don't want to.:
@thecpuwizard Okay whatever mate, considering you and @blakeyrat have kept on making up reasons why Git is evil. I don't believe you. Sorry.
Read back... I support Git when it is the right tool for the job.
-
@thecpuwizard so do I, so we don't have a disagreement. Brilliant.
However having such a huge code base isn't the norm. It is an exception.
-
@lucas1 said in We don't understand TFS and we don't want to.:
@thecpuwizard so do I, so we don't have a disagreement. Brilliant.
However having such a huge code base isn't the norm. It is an exception.
"The norm" depends very much on your sample set..... Of the many customers I have dealt with over the past 3 years [I have provided TFS consulting services for over 12], I don't think I have seen a single TPC what was under 250GB....
-
@thecpuwizard You are saying your clients have a code base almost as large as Windows ... I find that hard to believe.
-
@lucas1 said in We don't understand TFS and we don't want to.:
@thecpuwizard You are saying your clients have a code base almost as large as Windows ... I find that hard to believe.
I think we are using different meanings. The 3TB I was referring to (for example) has every bit of code written by a large company for the past 15 years (plus selected snapshots going to back to the 1980's) , with "projects" ranging from their financial accounting to their engineering embedded microcontrollers; every version, every branch, every checkin.
-
@thecpuwizard every time I say "That isn't realistic" you make up something more unrealistic.
Is Stephen Hawkins brain being back up on a 10000GB partition on your mum's laptop?
-
@thecpuwizard said in We don't understand TFS and we don't want to.:
The 3TB I was referring to (for example) has every bit of code written by a large company for the past 15 years (plus selected snapshots going to back to the 1980's) , with "projects" ranging from their financial accounting to their engineering embedded microcontrollers; every version, every branch, every checkin.
This is still exception. Most IT companies have not been going for over 30 years.
-
I had a chat on personal message with @TheCPUWizard and we were just misunderstanding each other.
-
@thecpuwizard said in We don't understand TFS and we don't want to.:
The 3TB I was referring to (for example) has every bit of code written by a large company for the past 15 years (plus selected snapshots going to back to the 1980's) , with "projects" ranging from their financial accounting to their engineering embedded microcontrollers; every version, every branch, every checkin.
Single mega-repositories can get large, especially if they're keeping binary artefacts like third-party libraries and non-trivial binary assets in there. I used to work on a team that did that. (We've never done it at organisational scale, but big universities do almost nothing at full organisational scale if they can help it.)
I think I prefer the modern practice of using more, smaller, single-subject repositories, especially as then the unit of versioning is more coherent. When the team I mentioned above migrated to using git, they agreed that moving to this style was a much better idea. (Extracting the version history from the SVN mega-repo that they'd previously been using was … painful… and one of the reasons I'm not too keen on SVN these days; it lets some awful practices fester.)
-
@dkf 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.:
The 3TB I was referring to (for example) has every bit of code written by a large company for the past 15 years (plus selected snapshots going to back to the 1980's) , with "projects" ranging from their financial accounting to their engineering embedded microcontrollers; every version, every branch, every checkin.
Single mega-repositories can get large, especially if they're keeping binary artefacts like third-party libraries and non-trivial binary assets in there. I used to work on a team that did that. (We've never done it at organisational scale, but big universities do almost nothing at full organisational scale if they can help it.)
I think I prefer the modern practice of using more, smaller, single-subject repositories, especially as then the unit of versioning is more coherent. When the team I mentioned above migrated to using git, they agreed that moving to this style was a much better idea. (Extracting the version history from the SVN mega-repo that they'd previously been using was … painful… and one of the reasons I'm not too keen on SVN these days; it lets some awful practices fester.)
I do not believe that either is universally better or worse; rather I have found that it is best to determine what is most effective in a given environment. Independence has advantages, but also limitations (same for centralization). By no means am I suggesting that everyone should use a "single mega-repository".
ps: The specific repository I was referring to was 99% pure source in terms of the items being "originals". Things like 3rd party libraries and other reusable generated artifacts were stored elsewhere. Due to the nature of the project(s) there is a fair amount of binary files (about 3%-5% of the files, but about 20%-25% of the space dues to lack of deltas) .
