We don't understand TFS and we don't want to.
-
UPDATE 2:
Things I forgot to mention (one of these if going to piss off @blakeyrat )
I had some permissions given to me on Monday afternoon for a particular server. Lets say they are "New_Developer", "Developer".
This broke TFS, but I didn't realise it until after 5pm when IT had gone home for the day. Guess what I couldn't do @blakeyrat ... I couldn't do a get latest and because we have that locks on I had stuff checked out that other developers couldn't change because my account was in a zombie state. This occurred until Tuesday mid-morning, when they just gave me super admin permissions of TFS because it basically stopped all 4 devs working. I then had to manually merge my changes as I copied and pasted the whole solution onto C: and then did an undo as I couldn't shelve-set.
With Git ... Everyone could have just carried on and I could have waited for IT to do their stuff without the other developers waiting.
-
@lucas1 said in We don't understand TFS and we don't want to.:
UPDATE 2:
Things I forgot to mention (one of these if going to piss off @blakeyrat )
I had some permissions given to me on Monday afternoon for a particular server. Lets say they are "New_Developer", "Developer".
This broke TFS, but I didn't realise it until after 5pm when IT had gone home for the day. Guess what I couldn't do @blakeyrat ... I couldn't do a get latest and because we have that locks on I had stuff checked out that other developers couldn't change because my account was in a zombie state. This occurred until Tuesday mid-morning, when they just gave me super admin permissions of TFS because it basically stopped all 4 devs working. I then had to manually merge my changes as I copied and pasted the whole solution onto C: and then did an undo as I couldn't shelve-set.
Well you (as an organization, not necessarily personally in each case) made at least 3 key errors to get to this state.
With Git ... Everyone could have just carried on and I could have waited for IT to do their stuff without the other developers waiting.
Aside from being able to check-in, so could they with TFS.
-
@thecpuwizard said in We don't understand TFS and we don't want to.:
Aside from being able to check-in, so could they with TFS.
No. Because everyone was locked out of file and project files (so you can't add files to the project as the project file is locked).
Also my project got screwed, and I had to manually merge after undoing everything which cost me about an hour when I was already a bit behind on a task and ended up with me working til 8pm yesterday.
TFS has to be understood very well for it to work well. As @Lorne-Kates said they are using it like source safe and it just fucking sucks.
Also TFS doesn't like you not working connected.
I've already got into a Git vs TFS bitching match where one person doesn't understand Git and just wants to bitch because as far as I am concerned he is more interested in bitching and moaning than learning. This problem would not have happened at all if we were using Git ... not without all of the failures that happened along the way. I could have just left IT to sort it out on their own time rather than the Scrum master involving everyone and making drama.
-
@lucas1 - Let's look at what a checkout is with TFVC....
a) It is a setting of status within TFS so that others can see that someone is working on a file.
b) If "exclusive" you are prohibited from setting the notification that you are working on the file if someone else is.
c) If you are using Server Workspaces [which does not mean what most people think it does] despite Local Workspaces being the recommendation for most cases for almost a decade, then the ReadOnly bit is set on your local copy (and you local copy is not your workspace!)So, lets take the most constrained. Server Workspaces, Someone else has an Exclusive Checkout. You want to work on the file...
Oh, such problems - solution: Remove the RO flag on the file!
Now you can make your changes, and test locally.
Need to share the work with other developers, put it in a Shelveset.
Need to kick of a build with the changes (perhaps for a release), do a build off of the Shelveset...
NOBODY is "locked out". The worst case (other than the limitation of not being able to check-in as I originally stated) is that one has to change an attribute of a file on the local file system
-
@thecpuwizard There was exclusive locks and VS would complain about it all the time. Also I had like a half of a changeset in my folder than was in a Zombie state in TFS which means I couldn't compile without editing about 15 projects. Apparently you think this is acceptable way to work ... the best I could do in that situation was precode and nothing more
As I said I don't hate TFS, but these guys aren't using it right and it is compounded by the limitations of the system itself.
-
@lucas1 said in We don't understand TFS and we don't want to.:
I am not a fucking idiot. I know that my car uses Diesel. I pick up the Diesel Pump.
Ok.
@lucas1 said in We don't understand TFS and we don't want to.:
Doesn't need a special designed fucking nozzle,
But wouldn't it be better if you had one? You wouldn't need it, but it also wouldn't hurt you any. And maybe someone else does need it. Maybe they're color blind, or dyslexic, you don't know.
Sure you're a super-mega-genius, that's great. You also believe there's some kind of correlation between "being smart" and "not making mistakes", which... sure why not. Let's go with it. But surely a super-mega-genius like yourself is smart enough to realize that society in general would be better-served by a foolproof system than a system that requires people to be super-mega-geniuses to operate correctly, yes?
@lucas1 said in We don't understand TFS and we don't want to.:
... Maybe that is why I also know more than you about source control.
Yeah that's a widely-held stereotype. Man, those British! So knowledgeable about source control! It's a staple of every sitcom around here.
@lucas1 said in We don't understand TFS and we don't want to.:
Btw this is a shite analogy because you can make all the same complaints with TFS if you knew how to use Git.
I have plenty of complaints about TFS. Problem is: compared to Git it looks like pure genius. So I usually don't bother voicing them.
@lucas1 said in We don't understand TFS and we don't want to.:
There are plenty of people disagreeing with your assessment, and while I don't like an appeal to popularity.
A lot of people eat McDonalds, too.
@lucas1 said in We don't understand TFS and we don't want to.:
Sometimes it is a good idea to shut the fuck up, take stock and then actually know wtf you are saying.
Have I said anything in this thread that's factually incorrect?
@lucas1 said in We don't understand TFS and we don't want to.:
You are someone that doesn't know what you are talking. You don't know what you are talking about because everything I have told you about how a mechanism works in Git and is a more than adequate replacement for similar things in TFS you have deflected or made up another problem.
You won't keep on point and thus why I know you are talking SHITE!Ok; like I said above I didn't get in this due to trolling, I was just expressing my honest opinion. However, I have to admit the fact that you're so mouth-foaming angry about this that you've forgotten how to type is amusing me to no end.
-
@blakeyrat I can't be bothered anymore. You won ... feel good about yourself.
You have not discussed in good faith once. I will keep on using a superior source control system when I can and I won't worry about you.
Have a nice day.
-
@lucas1 I already told you nobody on this forum, including myself, is going to defend the really shitty broken TFS configuration your company's using, so I'm not sure why you posted that or why you addressed it to me.
Look, once again:
"Git sucks" is not mutually-exclusive with "TFS sucks". In fact, all source control systems suck; I've yet to use a single one I'd even give a C+ grade.
You seem to think that since I'm saying Git sucks, I must therefore believe TFS is some holy great system from the heavens. You could not be more wrong.
-
@lucas1 said in We don't understand TFS and we don't want to.:
I can't be bothered anymore.
Did the anger mouth-foam coat your keyboard and now you're having too much trouble typing?
@lucas1 said in We don't understand TFS and we don't want to.:
You have not discussed in good faith once.
What have I said in bad faith?
@lucas1 said in We don't understand TFS and we don't want to.:
I will keep on using a superior source control system when I can and I won't worry about you.
Always a good policy to not give a shit what randos on the Internet think about you. Also glad to hear you'll be switching to TFS whenever possible.
-
@blakeyrat never was defending the bad TFS config. But still couldn't have happened if we were using Git.
That is a fact. It doesn't matter what the reasons are ... it couldn't not of happened. Because of how Git works vs TFS.
If you don't like it too bad.
-
@blakeyrat said in We don't understand TFS and we don't want to.:
What have I said in bad faith?
Almost everything. As far as I am concerned everytime I made a valid point in our initial disagreement post you just didn't understand and when corrected your reply was the equivalent of "I can't be bothered to learn". Like you don't have to learn TFS.
-
@lucas1 said in We don't understand TFS and we don't want to.:
That is a fact. It doesn't matter what the reasons are ... it couldn't not of happened.
Man I'm getting a headache.
I admit it. Or don't admit it. Or couldn't not of admitted not it?
@lucas1 said in We don't understand TFS and we don't want to.:
your reply was the equivalent of "I can't be bothered to learn".
You never explained how my level of education adds or removes features from Git. I've been horribly curious about that this entire conversation. What's the mechanism for my learning adding a feature to Git? Is it magical in nature? I must know.
-
@blakeyrat Not knowing what you are talking about or deliberately not educating yourself removes features because you are deciding not to learn about them.
Lets take a non-coding example:
People could choose not to use it, and would never get the full use of photoshop.
Is that clear enough for you?
-
@lucas1 said in We don't understand TFS and we don't want to.:
Not knowing what you are talking about immediately removes features because you are deciding not to learn about them.
Well it was your assertion originally. That if I somehow knew more about Git, Git would somehow grow the ability to do server-side stashes.
-
@blakeyrat It doesn't need to do server side stashes because you can just push you branch up and not request a PR. Job done, problem solved.
Again you don't understand Git and you are complaining about non-problems.
The real problem is with Git is that you won't let your irrational hatred for it go.
-
@lucas1 said in We don't understand TFS and we don't want to.:
It doesn't need to do server side stashes because you can just push you branch up and not request a PR.
You must have skipped where I discussed why that isn't useful. Please scroll up and re-read.
@lucas1 said in We don't understand TFS and we don't want to.:
Again you don't understand Git and you are complaining about non-problems.
Maybe; but even if I were, Git has plenty of problems to complain about. For example, it's shit-ass usability. And they all exist regardless of how educated I am.
@lucas1 said in We don't understand TFS and we don't want to.:
The real problem is with Git is that you won't let your irrational hatred for it go.
I'm being lectured on being irrational by the person who typed "couldn't not of happened". Great.
-
@blakeyrat said in We don't understand TFS and we don't want to.:
You must have skipped where I discussed why that isn't useful. Please scroll up and re-read.
You're reasons were bollox and basically showed you didn't know what you were on about.
Can't be arsed to read the rest as it is probably more of the same nonsense
-
@blakeyrat said in We don't understand TFS and we don't want to.:
I'm being lectured on being irrational by the person who typed "couldn't not of happened". Great.
Well I typoed. I do that all the time. Whatever.
-
@boomzilla 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.:
@boomzilla said in We don't understand TFS and we don't want to.:
Yes, where for some reason whoever is running the show told two people to do conflicting things, i.e., "your social problem," as he said originally.
Maybe it's an Agile shop and those were just plucked off the backlog.
Exactly.
I would hope those stories track their dependencies (must do A before B). Now, if while working on B you find out you also need to work on the image, you're still screwed. But I'd expect most of the time you'd know per story during planning what needs to touch approximately what.
-
@lucas1 said in We don't understand TFS and we don't want to.:
There was exclusive locks and VS would complain about it all the time.
You simply missed a setting [as do many, I completely agree there is a discoverability issue in this and other regards]
-
@mikehurley said in We don't understand TFS and we don't want to.:
Now, if while working on B you find out you also need to work on the image, you're still screwed. But I'd expect most of the time you'd know per story during planning what needs to touch approximately what.
Actually "My Work" and TFVC ShelveSets completely handle that problem. Suspend B, Do other activity, Resume B.
-
@thecpuwizard said in We don't understand TFS and we don't want to.:
@mikehurley said in We don't understand TFS and we don't want to.:
Now, if while working on B you find out you also need to work on the image, you're still screwed. But I'd expect most of the time you'd know per story during planning what needs to touch approximately what.
Actually "My Work" and TFVC ShelveSets completely handle that problem. Suspend B, Do other activity, Resume B.
I meant you may find out you need to touch that image as part of B, if you didn't originally plan on it.
-
@mikehurley said in We don't understand TFS and we don't want to.:
I meant you may find out you need to touch that image as part of B, if you didn't originally plan on it.
Lets look deeper at the "image/binary merge issue"... A key consideration is how long the exclusivity is required to avoid un-mergable therefore wasted work.
If it is on the matter of minutes, then go take a bio break, and problem solved....simply letting the person know they need to wait is a good solution....
If it is longer, then perhaps it is time to look at the design. Is this a single PNG that contains different elements that could possibly be composed? This would still have exclusivity on the smaller part, but perhaps that would be much shorter in duration, or less frequent..
-
@thecpuwizard I don't care for the most part. I rather my source control problems don't get in some zombie state. Git cannot get into that situation as of its nature.
-
@lucas1 said in We don't understand TFS and we don't want to.:
@thecpuwizard I don't care for the most part. I rather my source control problems don't get in some zombie state. Git cannot get into that situation as of its nature.
May you work (without the option to leave) with a bunch of artists who are all revision tracking material they are concurrently working one - have a great day.
-
@thecpuwizard I don't and it is still an unrealistic scenario and BTW Adobe offers a service as part of fucking Photoshop to track just this sensibly.
We are now making the argument again that people don't know how to use the tools they have and thus we should use them all badly.
Seriously this is bullshit.
-
@lucas1 said in We don't understand TFS and we don't want to.:
We are now making the argument again that people don't know how to use the tools they have and thus we should use them all badly.
Not at all.... Some tools have the ability for one person to know what the others are working on and provide some level of safety against accidentally wasting work....Other tools do not have this capability.... EOD.
-
@thecpuwizard Except that wasn't was the initial discussion was about and nor does what you say "save wasting work".
When you send a PR, it basically tried to do a merge against the current upstream (main or whatever it might be) and notify people that should be code reviewing your changes, that you have made a change, and that they should review it as part of their job.
I dunno what is so controversial about code review, rejecting if can't auto-merge (what TFS does btw).
It is simple to know what other are working on because it is TFS with Git, or you can add Git Hooks if you are using third party solutions. There are loads of good third party solutions as well.
I am fed up of pretending that it is the most difficult thing in the world when it simply isn't.
Not everyone's work flow is the same as yours. FFS.
-
@lucas1 - What is the hard part of understanding that a user should KNOW BEFORE THEY START WORKING that there will not be a merge necessary?????
-
@thecpuwizard Merges are part of developing. Everyone accepts that it will happen.
I think the PR system that git is the better way to do it .
Lets consider how a PR normally works
- Developer makes loads of commits to local git branch
- Developer pushes
- Developer then sends PR
- If there are conflicts developer has to merge them
- Other team members review and critique.
- Developer makes changes
- Developers pushing changes up
- It is merged (assuming other developers accept the changes)
- Server version of the dev branch is deleted.
Job done.
I think it is a better system IMHO.
EDIT: There is something I probably missed out but I don't think it is major ... that seems more of less correct.
-
@thecpuwizard Even if you were using WinMerge and different folders, would would still have to merge or cobber changes. You will just have to accept I am correct on this issue and read some source control fundamentals.
If there is more than one person writing code merges will happen.
-
@lucas1 You will just have to accept that Blakeyrat and TheCPUWizard are correct on this issue and read some source control fundamentals. Sometimes merges can't happen even when there's more than one person writing code.
There are some file formats that cannot be reasonably merged, only clobbered. Sometimes, multiple people can be assigned different tasks -- or even the same tasks, as I'm finding out in my company -- that touch the same unmergeable files at the same time. With the model you describe as preferable, no one knows of any problem until the first developer to finish files the PR, and all the work that all the other developers have done (assuming the PR is accepted) is now wasted and unusable. With the model Blakeyrat describes as reasonable, as soon as the first developer begins work, the other developers are aware that attempting future work right now would be wasted, and can try to obtain another assignment.
Yes, lock contention over a busy file can cause high overhead. Yes, managers shouldn't assign contentious tasks in the first place. Yes, giving monkeys string will have them cover the place in knots. That doesn't negate the existence of the problem locking is designed to solve, a problem which the PR system doesn't adequately address because it assumes competing work can always be merged in.
-
@twelvebaud they were talking about binary files and I was talking about anything in the repo tbh. They weren't being correct, they were being difficult.
Realistically you just replace whatever binary file is considered be the latest version for that branch. No you can't merge it, but you just communicate (imagine that) that it is the latest version and just take the latest . Problem fucking solved. Also there will be a record of the change.
These are as far as I am concerned more imagined problems to discredit a way of working that works for literally millions because 2 people don't like it.
It is just wankery and tbh I have little time for it.
I didn't bother reading the rest tbh after you accused me of not knowing fundamentals. I really can't be bothered arguing with someone that thinks I think I can merge binary files. This is such a misrepresentation of what I think, I cannot begin to correct it.
EDIT: Clarity.
-
@lucas1 said in We don't understand TFS and we don't want to.:
No. Like my car I know how to use a fuel pump probably by paying attention to what you are doing. Btw this is a shite analogy because you can make all the same complaints with TFS if you knew how to use Git. But you choose to be ignorant.
Make some. How does TFS suck?
-
@blakeyrat said in We don't understand TFS and we don't want to.:
@lucas1 I already told you nobody on this forum, including myself, is going to defend the really shitty broken TFS configuration your company's using, so I'm not sure why you posted that or why you addressed it to me.
Look, once again:
"Git sucks" is not mutually-exclusive with "TFS sucks". In fact, all source control systems suck; I've yet to use a single one I'd even give a C+ grade.
You seem to think that since I'm saying Git sucks, I must therefore believe TFS is some holy great system from the heavens. You could not be more wrong.
Why not roll your own?
-
@pie_flavor I never said I didn't like TFS. :D
-
@mrl 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.:
Frequent check-ins [average 10-40 minutes each developer who is actively working on code].
Heh, typically you don't get more than 2 commits in a day from me.
I'm pretty damn lazy myself...
-
@tsaukpaetra That was my commit history today most of them were front end mobile css stuff.
The rest was fucking MVC with the dropboxes ... Why does .NET make a fucking form submission more difficult that it should be?
Python I can just inspect the fucking response object. I perferred WebForms.
I think MVC is shit, I prefer Flask or WebForms ... there I've said it.
-
@lucas1 said in We don't understand TFS and we don't want to.:
I don't and it is still an unrealistic scenario
... No it's not. I work directly adjacent to an artist actually who meets this exact description...
-
@lucas1 said in We don't understand TFS and we don't want to.:
Merges are part of developing. Everyone accepts that it will happen.
Except for things that, by nature, are un-mergable...
-
@twelvebaud said in We don't understand TFS and we don't want to.:
With the model Blakeyrat describes as reasonable, as soon as the first developer begins work, the other developers are aware that attempting future work right now would be wasted, and can try to obtain another assignment.
This is actually 100% how it's done with UE4's source control, actually. You're essentially disallowed from working on/saving UASSET files (which is a binary format) if anyone else has them checked out (not even "exclusively"/"locked").
-
@lucas1 said in We don't understand TFS and we don't want to.:
Realistically you just replace whatever binary file is considered be the latest version for that branch. No you can't merge it, but you just communicate (imagine that) that it is the latest version and just take the latest . Problem fucking solved. Also there will be a record of the change.
Cue tons of build/cook errors because someone else decided to go around the system and clobber the file regardless and it no longer matches the rest of the code behind it. Yes this has happened. Multiple times. And it sucks every time, no matter what.
-
@blakeyrat said in We don't understand TFS and we don't want to.:
Fine; I'm pissing on a keyboard. Whatever.
It won't bother @GodEmperor . He buys his keyboards at the dollar store, so they're already cheap to replace. (And also, probably already covered in pee)
-
@lucas1 said in We don't understand TFS and we don't want to.:
I am not a fucking idiot.
[citation needed]
-
@GodEmperor said in We don't understand TFS and we don't want to.:
(so you can't add files to the project as the project file is locked).
Why the shit did anyone check out an entire project? Everyone at your company is as dumb as you!
-
@blakeyrat said in We don't understand TFS and we don't want to.:
But wouldn't it be better if you had one?
waitwhat...
Last I checked, diesel pumps DO have a special pumps. Every station I've ever seen has red or black pumps for gas, and yellow pumps for diesel. They are also explicitly marked "DIESEL". Also, the gastank holes are different sizes for gas and diesel so you explicitly CAN'T put a diesel nozzle into a gas tank (or vice versa). I may or may not know this first hand when I pumped gas before getting a coffee.
Is this different in the UK?!?
-
Okay, guys. I'm going to settle this in the time-proven, completely scientific way all arguments are settled.
.https://www.google.com?q=tfs+sucks
About 184,000 results.https://www.google.com?q=git+sucks
About 431,000 resultsThe end.
Filed under: Mercurial: about 180,000
-
@blakeyrat said in We don't understand TFS and we don't want to.:
But then you have to name it, and the names become permanent even if they're just shit like "checking in unfinished because I'm about to miss the bus".
They don't have to be permanent. Just delete the branch when you're done with it.
-
@greybeard It becomes permanent when you catch the bus, then come back the next morning and have to merge it with the rest of your work. If you delete the branch without merging it anywhere, it kind of defeats the entire purpose of the exercise.
-
@lorne-kates said in We don't understand TFS and we don't want to.:
@GodEmperor said in We don't understand TFS and we don't want to.:
(so you can't add files to the project as the project file is locked).
Why the shit did anyone check out an entire project? Everyone at your company is as dumb as you!
Not the entire project, just the project file [.csproj, .vbproj, etc that contains all of the meta-data and files included in the project].
It is rare that this file should be checkout (and even then as a shared, not exclusive) for more than a few minutes.
Need to add a class to your project...
a) Checkout (explicit or implicit) .csproj file
b) Add new .cs file to project with empty class
c) Check-in .csproj file along with new fileOne reason for this is that .csproj files are non-deterministic. Make one change, and the layout of the entire file may change (in fact this is the nature of every XML file, unless the schema declares "Sequence"). So merge can be tedious/painful/errorprone and require manual intervention. Having a checkout time as short of the above virtually eliminates it.
