We don't understand TFS and we don't want to.
-
I am currently working on a project with 7 other devs.
It is a ASP.NET MVC 4 or 5 project (I am mostly doing JS stuff). Another new developer and I were working on the same area of the code.
Everything is done on Main as that is their integration branch in TFS. This is mental in of itself.
Me and another developer mentioned we should probably have developer branches, an integration branch.
Two developers can't change the same file because there are exclusive locks. The dev I am working with forgot to "check in" and locked everyone out of making changes. So they just changed his password and went into his machine which probably had some personal stuff in there to shelveset it.
I have a meeting with my manager next week. But even me telling people to using a Stash / Shelveset is a political issue.
I've only just started this contract as a consultant and I've got a long way to go.
-
@lucas1 said in We don't understand TFS and we don't want to.:
Two developers can't change the same file because there are exclusive locks. The dev I am working with forgot to "check in" and locked everyone out. So they just changed his password and went into his machine which probably had some personal stuff in there to shelveset it.
Since I know people are going to use this as an opportunity to go "OMG MS tech SO BAD", unless they're using an ancient version, TFS does not lock files ("exclusively check out") by default, you have to go out of your way to do it.
-
@blakeyrat They turned on lock files, because somebody didn't fucking merge stuff properly and lost work as a result.
i.e. he was a retard.
EDIT: sure I prefer git these days but TFS isn't terrible and works quite well. So I don't have a major problem with it. They are just using it like retards. I am taking up with my manager on Monday or Tuesday. He isn't that savvy or source control but he knows something is wrong.
-
@blakeyrat BTW I know how you feel. I think Git is better IMO, but I used TFS a lot and it has it pros and cons over Git and other source control systems.
What is does is sensible.
-
@lucas1 The best part of this is that you got downvoted.
-
@lucas1 Switch to using a local workspace instead of a server workspace. (Requires TFS2012 or later. I'd say "I sure as hell hope you're on something more recent", but we only upgraded from TFS2012 to TFS2017 about six weeks ago...) Local workspaces ignore all locks entirely.
-
@boomzilla said in We don't understand TFS and we don't want to.:
@lucas1 The best part of this is that you got downvoted.
It's not so amusing when it's just you trying to attract attention to yourself.
-
@unperverted-vixen I will see if I can do that. I just shelve all my work at the end of the day at the moment.
-
@boomzilla said in We don't understand TFS and we don't want to.:
@lucas1 The best part of this is that you got downvoted.
Scripts.
-
@gąska 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.:
@lucas1 The best part of this is that you got downvoted.
Scripts.
Kiddies.
-
@tsaukpaetra said in We don't understand TFS and we don't want to.:
@gąska 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.:
@lucas1 The best part of this is that you got downvoted.
Scripts.
Kiddies.
-
@boomzilla I am just going to have to accept some downvotes I think.
-
@lucas1 said in We don't understand TFS and we don't want to.:
@blakeyrat They turned on lock files, because somebody didn't fucking merge stuff properly and lost work as a result.
i.e. he was a retard.
EDIT: sure I prefer git these days but TFS isn't terrible and works quite well. So I don't have a major problem with it. They are just using it like retards. I am taking up with my manager on Monday or Tuesday. He isn't that savvy or source control but he knows something is wrong.
To to clarify. I've done very large merges in TFS. When I worked in previous roles, I would regularly do merges of several hundred files and I became quite adept at doing very large merges.
So my procedure before merging from MAIN is:
- Shelve all pending changes.
- Check the shelveset actually happened.
- Undo pending changes
- Merge Main into my branch, all changes should be correct and I can just accept them
- Bring back down the shelveset and then fix/merge any conflicts.
- Smoke test my changes
- Merge back into main.
I do something quite similar when merging to MAIN.
The reason why I do it in that order is it makes my changes and changes that I don't have obvious (each set of changes will be on either side of the Diff). This makes things much easier. Also if I cock it up, it is really easy to go back to I simply undo the attempted merge and start again.
Git basically forces you into this process if you are following the PR, merge, (someone else in the team accepting changes). TFS big weakness is that it isn't forced and is the biggest weakness of classic TFS IMO.
-
@lucas1 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.:
@blakeyrat They turned on lock files, because somebody didn't fucking merge stuff properly and lost work as a result.
i.e. he was a retard.
EDIT: sure I prefer git these days but TFS isn't terrible and works quite well. So I don't have a major problem with it. They are just using it like retards. I am taking up with my manager on Monday or Tuesday. He isn't that savvy or source control but he knows something is wrong.
To to clarify. I've done very large merges in TFS. When I worked in previous roles, I would regularly do merges of several hundred files and I became quite adept at doing very large merges.
Have you checked with mental health professionals? This kind of traumatic experience doesn't leave your psyche unscarred. You have my deepest sympathy.
-
@gąska I have no idea what you are on about. I am just saying that I did a large number of changes correctly using the method described successfully. The reason I did it in a previous job because I was one of the few devs that could do it. I just had to get good at it because other people cocked it up a lot.
Look I know I am not liked here but not everything I say is insidious.
-
@lucas1 I did a fair share of huge merges too (1000+ conflicting lines), and it always took awfully long time and didn't work more often than it did. It's like reading C++ compile errors involving deeply nested templates - you certainly can become proficient in it, but you're not the same man you were before.
-
@gąska oh okay. I see what you are saying now. I literally into like a merge robot while doing it. It like a weird state where I am almost in a trance while I am doing it.
-
I have read most of this, but not every line...that being said. TFS (modern versions) fully support Git and also the centralized TFVC. So the usage of TFS is independent of the choice of centralized vs. distributed source management.
The real question is which (centralized or distributed) makes more sense for a given environment. For example if you are using Work Management) then that is centralized. Same for Build.
The ability to work independently (no connection to server or your teammates) can be advantageous. But it inherently means increased isolation and decreased collaboration.
-
@gąska said in We don't understand TFS and we don't want to.:
@lucas1 I did a fair share of huge merges too (1000+ conflicting lines), and it always took awfully long time and didn't work more often than it did. It's like reading C++ compile errors involving deeply nested templates - you certainly can become proficient in it, but you're not the same man you were before.
If I see commits of 1000 lines (totals, not conflicts) then I have usually found there is some underlying problem. Just look at the concept of a true code review. If there are 1000's of lines are you going to catch that breaking "for" to "foreach" change buried in a single line????
-
@thecpuwizard It is being used as sourcesafe. Because of reasons.
-
@lucas1 said in We don't understand TFS and we don't want to.:
@thecpuwizard It is being used as **********. Because of reasons.
TRIGGER THAT SHIT!
-
@dcon Sorry I used a swear word.
-
@lucas1 said in We don't understand TFS and we don't want to.:
@dcon Sorry I used a swear word.
Nah, it's not a swear word. At a company many years ago, we used that. It now causes serious PTSD!
-
@dcon I know it was terrible. I remember using it years ago and it wasn't pleasant.
-
@thecpuwizard said in We don't understand TFS and we don't want to.:
If I see commits of 1000 lines (totals, not conflicts) then I have usually found there is some underlying problem.
Tell me about it.
I have pending code review, the second from a coworker and project, which starts with a commit changing 20+ files. The first review took me three days to puzzle out all that was going on there. He obviously didn't take my note about it being too big.
So this time I'll have to take sterner measures. But I'm behind on the arbitrarily dictated timelines for my own project, so it's going to sit for a couple more days.
-
The upside of no code review: I can get away with changesets touching 100+ files.
(Not that I try to do that, but when collapsing four assemblies into one, sometimes there's just no avoiding it.)
-
@unperverted-vixen However, particularly in code cleanup, there is value in keeping the individual steps simple.
Sure, you're changing the way your pool allocator works and need to change every pool setup in the product, touching dozens of files. But you're not doing anything else, and the changes outside the pool allocator itself are trivial.
-
@thecpuwizard said in We don't understand TFS and we don't want to.:
@gąska said in We don't understand TFS and we don't want to.:
@lucas1 I did a fair share of huge merges too (1000+ conflicting lines), and it always took awfully long time and didn't work more often than it did. It's like reading C++ compile errors involving deeply nested templates - you certainly can become proficient in it, but you're not the same man you were before.
If I see commits of 1000 lines (totals, not conflicts) then I have usually found there is some underlying problem. Just look at the concept of a true code review. If there are 1000's of lines are you going to catch that breaking "for" to "foreach" change buried in a single line????
Depends on how much time you have to review. At my previous company, we routinely had code reviews that spanned days, sometimes whole week.
-
I am going to address this nonsense tomorrow.
If it isn't taken seriously, I will be leaving once the contract ends.
-
I'm getting old ... last time I played, it was still TF2 and you where required to wear a hat. This new TFS doesn't sound to appealing.
-
@luhmann said in We don't understand TFS and we don't want to.:
I'm getting old ... last time I played, it was still TF2 and you where required to wear a hat. This new TFS doesn't sound to appealing.
I laughed far too hard at this.
-
@gąska 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.:
@gąska said in We don't understand TFS and we don't want to.:
@lucas1 I did a fair share of huge merges too (1000+ conflicting lines), and it always took awfully long time and didn't work more often than it did. It's like reading C++ compile errors involving deeply nested templates - you certainly can become proficient in it, but you're not the same man you were before.
If I see commits of 1000 lines (totals, not conflicts) then I have usually found there is some underlying problem. Just look at the concept of a true code review. If there are 1000's of lines are you going to catch that breaking "for" to "foreach" change buried in a single line????
Depends on how much time you have to review. At my previous company, we routinely had code reviews that spanned days, sometimes whole week.
How does that work with things like continuous delivery? Most of my clients (meaning just over 50%) are now doing deployments to production daily :)
-
@thecpuwizard said in We don't understand TFS and we don't want to.:
How does that work with things like continuous delivery? Most of my clients (meaning just over 50%) are now doing deployments to production daily
Continuously deliver on the integration branch, develop in a side branch. Code review is required before merging from the side branch to integration.
-
@unperverted-vixen 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.:
How does that work with things like continuous delivery? Most of my clients (meaning just over 50%) are now doing deployments to production daily
Continuously deliver on the integration branch, develop in a side branch. Code review is required before merging from the side branch to integration.
Yes, but I was referring to rate of progression - how long from the time a developer types in "a line of code" till the time when that is running in production. For the organizations (many highly regulated and even safety critical) this has been reduced from weeks (or longer) to hours!
This means that the CODE review process must be timely and fast. The most effective way (that I know of) to achieve this is to have the changes be very small so that an appropriate level of review can be done in minutes (<5).
-
@thecpuwizard said in We don't understand TFS and we don't want to.:
Yes, but I was referring to rate of progression - how long from the time a developer types in "a line of code" till the time when that is running in production.
About half a year on average. Big reviews was the least of our problems.
-
@gąska 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.:
Yes, but I was referring to rate of progression - how long from the time a developer types in "a line of code" till the time when that is running in production.
About half a year on average. Big reviews was the least of our problems.
Sounds like a flash back to the 1990's (or earlier).
-
@ben_lubar said in We don't understand TFS and we don't want to.:
Scrip Kitties: we can't pay you, but here, have a cat.
-
This is the way source code """""management"""" has been done at every .Net shop I've ever worked at. Here's how it goes:
- At some point way in the past, they used SourceSafe.
- Whoever set up SourceSafe was an idiot. So is whoever chose to use it.
- "Exclusive Checkout" is the default
- Maybe at one point they tried this whizz-bang woo hoo "academic" thing called Branching
- Two devs, at one point in time, worked on some code that crossed over
- When merging the branch back in, a Conflict occurred that needed manual intervention
- All these monkey-farts starred at the screen and saw two windows and red squiggles and it scared them
- Each dev refused to "understand" what the other dev's code was, because "it's too complex"
- Basically, when faced with a merge, each snot-stain shouted "no me"
- Some other dev spent 16 hours "merging" three lines of code, and it still broke
- A manager saw this and came to a conclusion. The conclusion was "My devs are braindead idiots, and if they can't read the MSDN article on The Basics Of Source Code Management and understand it, I'll jettison them all and get someone who can learn to do their fucking job"
- hahahaha, just kidding, the manager go scared also because "technology", just looked at numbers on the timesheet, and assumed that every time someone "mirages a branch" or whatever, it'll cost 16 hours.
- Than manager then screamed at everyone about how they are incompetent and don't know what they're doing and we will NEVER do branching again!
- Several years pass. Developers change. Technology changes. But SourceSafe is still set up to "Exclusive Checkout".
- Every new dev gets taught how to checkout code (including yelling across the room for someone else to check in File.aspx). If they mention Branching, they're told "that's too difficult, it isn't for us"
- The culture of Exclusive Checkout is now mark of the zeitgeist of the comapny.
- Eventually someone installs TFS, because now that it's several years old-- and because the last SoureSafe release was 2005-- maybe it's time to actually pay attention to the mission critical piece of software that controls the source code.
- Everyone converts to TFS.
- Two devs work on the same file, both check in, and someone's code gets clobbered.
- Management freaks the absolute fuck out, going literally out of their minds, mouth-frothing insane. THIS. IS. NOT. HOW. IT. SHOULD. WORK.
- IT manager googles "TFS exclusive checkout", and gets this question from Raj from 2008. Raj is also an IT manager who has live through the above at his own company. You'll notice his question is from 2008, which is the same year TFS was released. Raj is Patient Zero. His experience isn't special or unique in any way. He just happened to be the first one to ask "How do I sourcesafe with tfs"?
- Now the answer is there, and is the top hit on Google. The mystical incantations and rituals described have been done thousands-- millions of times even, at companies just like yours.
- And still, no one understands what Branching is.
-
@lorne-kates said in We don't understand TFS and we don't want to.:
Maybe at one point they tried this whizz-bang woo hoo "academic" thing called Branching
I read this, and for some reason my brain went "Bran-ching": How to make money (cha-ching!) from selling whole-grain food products.
-
@hardwaregeek said in We don't understand TFS and we don't want to.:
How to make money (cha-ching!) from selling whole-grain food products.
Oh, that's easy. Whole-grain is a term completely co-opted by the sociopaths in marketing. It sounds healthy, but depending on the local laws, and the exact wording they use, it can often mean that up to 70% of the grain has actually been processed away, leaving you without the benefits of the fiber or the nutritional content of the wheat germ. But since people associate "brown bread" with "healthy bread", they dump some molasses into it to make it look brown (and also upping the sugar content).
You now have a cheap piece of shit bread that LOOKS LIKE and can be MARKETED AS something that sounds like a premium, high-quality, extra-healthy product. So you slap at 2x multiplier on the price (which your production costs go way down), and rake in the profits.
That's how you make money from selling whole-grain food products.
-
@lorne-kates said in We don't understand TFS and we don't want to.:
This is the way source code """""management"""" has been done at every .Net shop I've ever worked at. Here's how it goes:
- At some point way in the past, they used SourceSafe.
- Whoever set up SourceSafe was an idiot. So is whoever chose to use it.
- "Exclusive Checkout" is the default
- Maybe at one point they tried this whizz-bang woo hoo "academic" thing called Branching
- Two devs, at one point in time, worked on some code that crossed over
- When merging the branch back in, a Conflict occurred that needed manual intervention
- All these monkey-farts starred at the screen and saw two windows and red squiggles and it scared them
- Each dev refused to "understand" what the other dev's code was, because "it's too complex"
- Basically, when faced with a merge, each snot-stain shouted "no me"
- Some other dev spent 16 hours "merging" three lines of code, and it still broke
- A manager saw this and came to a conclusion. The conclusion was "My devs are braindead idiots, and if they can't read the MSDN article on The Basics Of Source Code Management and understand it, I'll jettison them all and get someone who can learn to do their fucking job"
- hahahaha, just kidding, the manager go scared also because "technology", just looked at numbers on the timesheet, and assumed that every time someone "mirages a branch" or whatever, it'll cost 16 hours.
- Than manager then screamed at everyone about how they are incompetent and don't know what they're doing and we will NEVER do branching again!
- Several years pass. Developers change. Technology changes. But SourceSafe is still set up to "Exclusive Checkout".
- Every new dev gets taught how to checkout code (including yelling across the room for someone else to check in File.aspx). If they mention Branching, they're told "that's too difficult, it isn't for us"
- The culture of Exclusive Checkout is now mark of the zeitgeist of the comapny.
- Eventually someone installs TFS, because now that it's several years old-- and because the last SoureSafe release was 2005-- maybe it's time to actually pay attention to the mission critical piece of software that controls the source code.
- Everyone converts to TFS.
- Two devs work on the same file, both check in, and someone's code gets clobbered.
- Management freaks the absolute fuck out, going literally out of their minds, mouth-frothing insane. THIS. IS. NOT. HOW. IT. SHOULD. WORK.
- IT manager googles "TFS exclusive checkout", and gets this question from Raj from 2008. Raj is also an IT manager who has live through the above at his own company. You'll notice his question is from 2008, which is the same year TFS was released. Raj is Patient Zero. His experience isn't special or unique in any way. He just happened to be the first one to ask "How do I sourcesafe with tfs"?
- Now the answer is there, and is the top hit on Google. The mystical incantations and rituals described have been done thousands-- millions of times even, at companies just like yours.
- And still, no one understands what Branching is.
Alas I have seen the same thing far too often (but not nearly) "every" time.
Also TFS was release in 2005. 2008 was the second release.
Finally, in many cases branching has become more of a problem than a solution in various scenarios [there are plenty of other scenarios where it is fantastic].
-
@thecpuwizard I've yet to see a case where 1 dev working at a time is preferable to everyone working all the time.
-
@gąska said in We don't understand TFS and we don't want to.:
@thecpuwizard I've yet to see a case where 1 dev working at a time is preferable to everyone working all the time.
Then you haven't met my co-workers.
-
@lorne-kates said in We don't understand TFS and we don't want to.:
This is the way source code """""management"""" has been done at every .Net shop I've ever worked at. Here's how it goes:
- At some point way in the past, they used SourceSafe.
- Whoever set up SourceSafe was an idiot. So is whoever chose to use it.
- "Exclusive Checkout" is the default
- Maybe at one point they tried this whizz-bang woo hoo "academic" thing called Branching
- Two devs, at one point in time, worked on some code that crossed over
- When merging the branch back in, a Conflict occurred that needed manual intervention
- All these monkey-farts starred at the screen and saw two windows and red squiggles and it scared them
- Each dev refused to "understand" what the other dev's code was, because "it's too complex"
- Basically, when faced with a merge, each snot-stain shouted "no me"
- Some other dev spent 16 hours "merging" three lines of code, and it still broke
- A manager saw this and came to a conclusion. The conclusion was "My devs are braindead idiots, and if they can't read the MSDN article on The Basics Of Source Code Management and understand it, I'll jettison them all and get someone who can learn to do their fucking job"
- hahahaha, just kidding, the manager go scared also because "technology", just looked at numbers on the timesheet, and assumed that every time someone "mirages a branch" or whatever, it'll cost 16 hours.
- Than manager then screamed at everyone about how they are incompetent and don't know what they're doing and we will NEVER do branching again!
- Several years pass. Developers change. Technology changes. But SourceSafe is still set up to "Exclusive Checkout".
- Every new dev gets taught how to checkout code (including yelling across the room for someone else to check in File.aspx). If they mention Branching, they're told "that's too difficult, it isn't for us"
- The culture of Exclusive Checkout is now mark of the zeitgeist of the comapny.
- Eventually someone installs TFS, because now that it's several years old-- and because the last SoureSafe release was 2005-- maybe it's time to actually pay attention to the mission critical piece of software that controls the source code.
- Everyone converts to TFS.
- Two devs work on the same file, both check in, and someone's code gets clobbered.
- Management freaks the absolute fuck out, going literally out of their minds, mouth-frothing insane. THIS. IS. NOT. HOW. IT. SHOULD. WORK.
- IT manager googles "TFS exclusive checkout", and gets this question from Raj from 2008. Raj is also an IT manager who has live through the above at his own company. You'll notice his question is from 2008, which is the same year TFS was released. Raj is Patient Zero. His experience isn't special or unique in any way. He just happened to be the first one to ask "How do I sourcesafe with tfs"?
- Now the answer is there, and is the top hit on Google. The mystical incantations and rituals described have been done thousands-- millions of times even, at companies just like yours.
- And still, no one understands what Branching is.
Alas I have seen the same thing far too often (but not nearly) "every" time.
Also TFS was release in 2005. 2008 was the second release.
Finally, in many cases branching has become more of a problem than a solution in various scenarios [there are plenty of other scenarios where it is fantastic].
@gąska said in We don't understand TFS and we don't want to.:
@thecpuwizard I've yet to see a case where 1 dev working at a time is preferable to everyone working all the time.
Not sure how that relates to anything I have posted....
As an example, currently working with a team of 8 developers. Frequent check-ins [average 10-40 minutes each developer who is actively working on code]. All committed to same (only non-archive) branch. Occasional automated merges, but conflicts (ie manual operation required) typically happens about once per week per developer and is trivial to address. Every check-in must build and pass primary tests prior to being actually committed into the repository.
-
@thecpuwizard said in We don't understand TFS and we don't want to.:
@gąska 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.:
Yes, but I was referring to rate of progression - how long from the time a developer types in "a line of code" till the time when that is running in production.
About half a year on average. Big reviews was the least of our problems.
Sounds like a flash back to the 1990's (or earlier).
Very small commits with a short distance to deployment works when you're close to the optimum. Bigger steps work better when you've got further to go (for whatever reason) as you're less confounded by the need to keep everything working 100%.
Some projects have a mix of the two. (It's not as insane as it sounds; different types of improvements fit the two styles better.)
-
@hardwaregeek said in We don't understand TFS and we don't want to.:
I read this, and for some reason my brain went "Bran-ching": How to make money (cha-ching!) from selling whole-grain food products.
It sounds to me like some sort of ancient form of Chinese divination based on horse feed.
-
@thecpuwizard said in We don't understand TFS and we don't want to.:
Every check-in must build and pass primary tests prior to being actually committed into the repository.
A.k.a. hide your intermediate states, Mavis; they're embarrassing us!
-
@thecpuwizard You guys notice how CPUWizard has changed from bragging about how rich and successful he is and how Intel gives him prototype hardware to bragging about how many commits his team makes in an hour? Like I've seen this now 5-6 times now, yes, your team makes a lot of commits, great, we get it.
-
@lorne-kates said in We don't understand TFS and we don't want to.:
This is the way source code """""management"""" has been done at every .Net shop I've ever worked at. Here's how it goes:
- At some point way in the past, they used SourceSafe.
- Whoever set up SourceSafe was an idiot. So is whoever chose to use it.
- "Exclusive Checkout" is the default
- Maybe at one point they tried this whizz-bang woo hoo "academic" thing called Branching
- Two devs, at one point in time, worked on some code that crossed over
- When merging the branch back in, a Conflict occurred that needed manual intervention
- All these monkey-farts starred at the screen and saw two windows and red squiggles and it scared them
- Each dev refused to "understand" what the other dev's code was, because "it's too complex"
- Basically, when faced with a merge, each snot-stain shouted "no me"
- Some other dev spent 16 hours "merging" three lines of code, and it still broke
- A manager saw this and came to a conclusion. The conclusion was "My devs are braindead idiots, and if they can't read the MSDN article on The Basics Of Source Code Management and understand it, I'll jettison them all and get someone who can learn to do their fucking job"
- hahahaha, just kidding, the manager go scared also because "technology", just looked at numbers on the timesheet, and assumed that every time someone "mirages a branch" or whatever, it'll cost 16 hours.
- Than manager then screamed at everyone about how they are incompetent and don't know what they're doing and we will NEVER do branching again!
- Several years pass. Developers change. Technology changes. But SourceSafe is still set up to "Exclusive Checkout".
- Every new dev gets taught how to checkout code (including yelling across the room for someone else to check in File.aspx). If they mention Branching, they're told "that's too difficult, it isn't for us"
- The culture of Exclusive Checkout is now mark of the zeitgeist of the comapny.
- Eventually someone installs TFS, because now that it's several years old-- and because the last SoureSafe release was 2005-- maybe it's time to actually pay attention to the mission critical piece of software that controls the source code.
- Everyone converts to TFS.
- Two devs work on the same file, both check in, and someone's code gets clobbered.
- Management freaks the absolute fuck out, going literally out of their minds, mouth-frothing insane. THIS. IS. NOT. HOW. IT. SHOULD. WORK.
- IT manager googles "TFS exclusive checkout", and gets this question from Raj from 2008. Raj is also an IT manager who has live through the above at his own company. You'll notice his question is from 2008, which is the same year TFS was released. Raj is Patient Zero. His experience isn't special or unique in any way. He just happened to be the first one to ask "How do I sourcesafe with tfs"?
- Now the answer is there, and is the top hit on Google. The mystical incantations and rituals described have been done thousands-- millions of times even, at companies just like yours.
- And still, no one understands what Branching is.
Alas I have seen the same thing far too often (but not nearly) "every" time.
Also TFS was release in 2005. 2008 was the second release.
Finally, in many cases branching has become more of a problem than a solution in various scenarios [there are plenty of other scenarios where it is fantastic].
@gąska said in We don't understand TFS and we don't want to.:
@thecpuwizard I've yet to see a case where 1 dev working at a time is preferable to everyone working all the time.
Not sure how that relates to anything I have posted....
As an example, currently working with a team of 8 developers. Frequent check-ins [average 10-40 minutes each developer who is actively working on code]. All committed to same (only non-archive) branch. Occasional automated merges, but conflicts (ie manual operation required) typically happens about once per week per developer and is trivial to address. Every check-in must build and pass primary tests prior to being actually committed into the repository.
-
@blakeyrat said in We don't understand TFS and we don't want to.:
@thecpuwizard You guys notice how CPUWizard has changed from bragging about how rich and successful he is and how Intel gives him prototype hardware to bragging about how many commits his team makes in an hour? Like I've seen this now 5-6 times now, yes, your team makes a lot of commits, great, we get it.
It's not about me at all. It is all about the companies who are doing this and what is regularly being achieved in the industry. It just makes me sad when so many seem to be stuck in the "this WTF scenario is normal".
