We don't understand TFS and we don't want to.
-
@thecpuwizard Here's the thing. You preach a lot about "best practices", but never explain why those work well. It comes across (to me at least) as bragging mixed with evangelism.
-
I wish I could use TFVC again...
There are so many things that would make sense to do as shelvesets, but people get upset if they see extra branches sometimes here. And while merge conflicts are more troublesome, I saw people delete my work less :/
-
@magus said in We don't understand TFS and we don't want to.:
people get upset if they see extra branches sometimes here
TR
-
@lorne-kates said in We don't understand TFS and we don't want to.:
every time someone "mirages a branch"
I wish some of my cow-orkers' branches were mirages.
-
@benjamin-hall It's just bragging.
-
@greybeard said in We don't understand TFS and we don't want to.:
pending code review...changing 20+ files.
The decision is apparently to merge without review.
-
@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.
He's really committed to the bullshit.
-
@lucas1 said in We don't understand TFS and we don't want to.:
Main as that is their integration branch in TFS
Which backend? TFVC or Git?
@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.
TFVC, I see…
Which version? Git backend is available from 2013 and default from 2015 (though you'll probably still see TFVC for projects migrated from older version, because the migration itself is simple, but the switch to Git is not).
Anyway, exclusive locks are
∞.@lucas1 said in We don't understand TFS and we don't want to.:
Shelveset
They are, unfortunately, Useless™.
May I suggest a partisan action using git-tfs?
I use it and it works well. We don't have explicit locks, but we are subcontracting to a company that's very reluctant to upgrade from old TFS 2012. So first some colleagues (I immediately joined when I came here) started using it locally and then we've set up a script that runs
git tfs fetchrepeatedly and pushes it to a central repo so we have a common baseline for sharing patches (because otherwise the imports may diverge). Everybody exports themselves, so muggles can't tell except by the funny workspace names it creates that nobody normally sees.You can start using it locally to shield yourself from the problems a bit, which should help you feel better, and then it might give you some persuasive leverage if you can show it helped your productivity.
@lucas1 said in We don't understand TFS and we don't want to.:
political issue
Yeah, that makes it a lot worse.
@lucas1 said in We don't understand TFS and we don't want to.:
They turned on lock files, because somebody didn't fucking merge stuff properly and lost work as a result.
This is actually a great argument for Git or other DVCS. These will make you first commit and then merge (update/get), so if you screw that up, you can always start over while your work is safely stored in the commit.
@lucas1 said in We don't understand TFS and we don't want to.:
I used TFS a lot and it has it pros and cons over Git and other source control systems.
Well, the newer versions are Git. And you can get the best of both with git-tfs.
@unperverted-vixen said in We don't understand TFS and we don't want to.:
we only upgraded from TFS2012 to TFS2017 about six weeks ago...
Lucky you. We still didn't. We suggested it to our technical leader almost a year ago. He wants to. But the server is used by several projects and coordinating the upgrade is a political nightmare.
@lucas1 said in We don't understand TFS and we don't want to.:
So my procedure before merging from MAIN is:
[…]
Git basically forces you into this process if you are following the PR, mergeThe point is it basically forces the process always.
git pullwill refuse to proceed if it has uncommitted changes to file that are modified upstream.
-
@bulb said in We don't understand TFS and we don't want to.:
Lucky you. We still didn't. We suggested it to our technical leader almost a year ago. He wants to. But the server is used by several projects and coordinating the upgrade is a political nightmare.
What would be particularly fun is if each of the other projects is having the same conversation and deciding to not try to upgrade for the same reason. ;)
-
@dkf It would, but it's not. The problem is that each project leader is narrowly focused on their own issues and nobody wants to consider the cross-project concerns, because they'll only risk having a red cell in their deadlines table and no benefit from it.
If there was somebody there with them who could sell them the advantages of the new version—which is vastly superior in most features—they could probably persuade them. But the people at the customer mostly don't give enough fucks and from the subcontractor position we don't get to talk to them enough. So inevitably somebody points out a risk or two and without anybody there to dispel the fear they just drop the idea, because
.
-
@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.
-
@bulb 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.:
Shelveset
They are, unfortunately, Useless™.
How so? Granted, Visual Studio could have done a better job at allowing them to be migrated across branches (now I have to use a command line tool like some Unix plebeian), but other than that it backs up changes to somewhere other than my current PC just fine.
Git meanwhile can only do this if you have a "forked repo" on a server somewhere to which you can push branches or if you have a convention of pushing of pushing temporary branches to the main repo with names like
bulb-wip-feature-xxx.@bulb said in We don't understand TFS and we don't want to.:
May I suggest a partisan action using git-tfs?
I use it and it works well. We don't have explicit locks, but we are subcontracting to a company that's very reluctant to upgrade from old TFS 2012. So first some colleagues (I immediately joined when I came here) started using it locally and then we've set up a script that runs
git tfs fetchrepeatedly and pushes it to a central repo so we have a common baseline for sharing patches (because otherwise the imports may diverge). Everybody exports themselves, so muggles can't tell except by the funny workspace names it creates that nobody normally sees.You can start using it locally to shield yourself from the problems a bit, which should help you feel better, and then it might give you some persuasive leverage if you can show it helped your productivity.
Eh, I hope you only use it some place where they don't use branches in TFVC. I wouldn't trust such git bridges to get the merge metadata right, only leaving you hanging when someone uses vanilla TFVC to do a merge.
Of course, this doesn't seem to be the case in @Lucas1's situation, although he might still have trouble when pushing from his local git to TFS and somebody has a file locked. You might not want to gather too much of a backlog of non-pushed commits in that case so that you can keep communicating "I'm working on file X".
@bulb 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.:
They turned on lock files, because somebody didn't fucking merge stuff properly and lost work as a result.
This is actually a great argument for Git or other DVCS. These will make you first commit and then merge (update/get), so if you screw that up, you can always start over while your work is safely stored in the commit.
Your faith in the mouth-breathers at Lucas' workplace is exemplary but misplaced. If they can "lose" work in TFVC, they can "lose" work in git. In either scenario the changes should have been part of the history (at least if they did use "take mine") and yet they still made enough of a stink that everyone condoned enabling the auto-file-locking on their TFVC server.
@lucas1 said in We don't understand TFS and we don't want to.:
I used TFS a lot and it has it pros and cons over Git and other source control systems.
Well, the newer versions are Git. And you can get the best of both with git-tfs.
Well, no, they support both git as well as TFVC. You still need to go out of your way to create git repositories so you you do need to push people a little bit.
-
@jbert said in We don't understand TFS and we don't want to.:
How so? Granted, Visual Studio could have done a better job at allowing them to be migrated across branches
Exaggerating a bit. But Visual Studio could have, in the first place, done a better job in being able to keep applied shelveset separate. You unshelve something and it simply becomes entangled with your changes. So if you have a shelved work from colleague that you need to test something against (which was our usual use-case early in this project)…
@jbert said in We don't understand TFS and we don't want to.:
Eh, I hope you only use it some place where they don't use branches in TFVC. I wouldn't trust such git bridges to get the merge metadata right, only leaving you hanging when someone uses vanilla TFVC to do a merge.
I wouldn't use it to do a merge between TFS branches. But we do that very rarely and @lucas1 explicitly said they don't do it either.
Also, our project layout is brain-damaged, as we work in a folder that contains 7 separate “components”, which are the branching points. So creating a branch actually means creating 7 of them and merging means merging 7 of them on consistent labels. It makes some sense, as some of them are shared between projects and the rest is not, but it should be just 2 components (the shared framework and the project) and not 7. Of course we import it in Git as single repo, so Git-Tfs does not understand the branch metadata a iota. Doesn't matter; we just work in git and then push to the central branch in TFS.
@jbert said in We don't understand TFS and we don't want to.:
Your faith in the mouth-breathers at Lucas' workplace is exemplary but misplaced.
That kind of thing is usually, at least in my experience, some manager who last programmed 20 years ago still fearing it, because it was pain back then. When you can demonstrate it is not a problem any more, they may yield.
@jbert said in We don't understand TFS and we don't want to.:
Well, no, they support both git as well as TFVC. You still need to go out of your way to create git repositories so you you do need to push people a little bit.
They support both, but as far as I can tell, Git is default for new projects since 2015. Switching old projects is pain, I know.
-
@bulb said in We don't understand TFS and we don't want to.:
May I suggest a partisan action using git-tfs?
Thanks for this. We're not using TFS yet, but I know now git-svn is a thing that will help me with our eventual migration from SVN+Bugnet, which we've been using since our company ditched SourceSafe, to TFS+Git.
I imagine I'll have some bumps with the branches in SVN, but at least we should be able to use this in the interim of getting everything over into Git-backed TFS.
-
@spencer said in We don't understand TFS and we don't want to.:
I imagine I'll have some bumps with the branches in SVN
The svn→git import process isn't too awful provided you know where your trunk, branches and tags are (and provided you've actually used the three types of things in svn as that; that's what caused us a lot of pain when we migrated because we'd put trunks in branches in tags in branches
). The commands to do it are quite arcane, but it's a pain that you can dry-run easily enough; it's trivial to practice until you get it right, then do the real migration. IIRC (and I warn it's been a few years) you use svn-git then do a bare git repository clone and then push the result (once you're happy with it) to your new repository store.I have no idea what extra wrinkles will be involved when you have TFS involved.
-
@bulb said in We don't understand TFS and we don't want to.:
@unperverted-vixen said in We don't understand TFS and we don't want to.:
we only upgraded from TFS2012 to TFS2017 about six weeks ago...
Lucky you. We still didn't. We suggested it to our technical leader almost a year ago. He wants to. But the server is used by several projects and coordinating the upgrade is a political nightmare.
You can't even get the downtime on a weekend? (We've got about 150 projects on the server, but thanks to our hierarchy I only had to coordinate this with about ten people responsible for all of them. They were all fine with 12-24 hours of downtime starting on a Friday night...)
-
@unperverted-vixen said in We don't understand TFS and we don't want to.:
@bulb said in We don't understand TFS and we don't want to.:
@unperverted-vixen said in We don't understand TFS and we don't want to.:
we only upgraded from TFS2012 to TFS2017 about six weeks ago...
Lucky you. We still didn't. We suggested it to our technical leader almost a year ago. He wants to. But the server is used by several projects and coordinating the upgrade is a political nightmare.
You can't even get the downtime on a weekend? (We've got about 150 projects on the server, but thanks to our hierarchy I only had to coordinate this with about ten people responsible for all of them. They were all fine with 12-24 hours of downtime starting on a Friday night...)
It's not about downtime. It's about fearing this or that might not migrate correctly and disrupting the work. And general fear of change.
-
@bulb said in We don't understand TFS and we don't want to.:
Well, the newer versions are Git.
The TFS protocol still exists and is superior to Git in many, many ways.
To give just one example, Git has nothing equivalent to those "useless ™" server-side shelvesets.
-
@dkf said in We don't understand TFS and we don't want to.:
The svn→git import process isn't too awful provided you know where your trunk, branches and tags are
As long as your SVN repo isn't on SourceForge where time has corrupted some revisions (and SF
s). Once I id'd those revisions and skipped them, then conversion worked well.I did several practice runs before I had my git repo ready. Then just pushed that to github.
-
@blakeyrat said in We don't understand TFS and we don't want to.:
Git has nothing equivalent to those "useless ™" server-side shelvesets
It does. Developer branches. And they are more useful, because they can contain multiple changesets.
If you don't have a space where you can push random work in progress on the server (usually
user/<username>/oru/<username>or similar), that's an organisation problem, not a technical one.
-
Something else Git doesn't have which sometimes annoys my Obsessive-Compulsive side: you can't edit Git comment messages* after the fact, while you can do so in TFVC (at least if you have sufficient permissions).
* History rewriting excluded: you can but you shouldn't unless you are 110% sure that it won't break anyone else's repo.
-
@bulb 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.:
Git has nothing equivalent to those "useless ™" server-side shelvesets
It does. Developer branches. And they are more useful, because they can contain multiple changesets.
If you don't have a space where you can push random work in progress on the server (usually
user/<username>/oru/<username>or similar), that's an organisation problem, not a technical one.Totally different. The concept of a Shelveset is short term, and no retention. If I want to share a set of files with another developer (and just that one other developer) so they can take a look, or if I want to submit code to the build environment without having a record in SCM, then TFVC can easily do it.
Using a Fileshare is also different because it does not have the integration points with the rest of the eco system.
-
@blakeyrat I would disagree, but I am a filthy web developer.
-
UPDATE
Well I found out what the reason was today why there can only be 3 branches. Basically the lead dev is trying to make sure that there aren't too many projects. Basically he is trying to make up poor project management by arbitrarly restricting the number of branches so people can't work on too much at the same time.
The mutual fucking locks is still dumb. I can argue against it now, now I fully understand the problem and the problem is the business / lack of project management.
-
@lucas1 said in We don't understand TFS and we don't want to.:
I would disagree, but I am a filthy web developer.
Disagree about what?
It's a fact that TFS has shelvesets (aka. server-side stashes) and Git does not. It's also a fact that TFS has optional file locking while Git does not. I guess you can disagree with facts, but seems like a waste of time.
-
Why would you have mutual locks in a distributed source control system? The whole concept doesn't make any sense in Git. It cannot be enforced.
If you don't want to merge someone's work, don't accept their PR. Mutual locks aren't needed, PR permissions and code review fix this. Which is the proper way to address this problem rather than arbitrary like the company I am working for make it difficult to checkin/push your work.
As for Shelvesets, just push checkout a new branch from your existing working branch and push it to the server. You have the same functionality of a shelvesets. Also you know you have these things called stashes that are locally.
I don't think you really understand Git. I used to bitch and moan about it until I learned how it work.
-
@lucas1 said in We don't understand TFS and we don't want to.:
Why would you have mutual locks in a distributed source control system?
So people don't stomp over other people's changes to a binary file that Git has no clue how to merge.
@lucas1 said in We don't understand TFS and we don't want to.:
The whole concept doesn't make any sense in Git. It cannot be enforced.
Git doesn't have to be militantly distributed all the time forever. That's a design decision they chose, not some God-delivered rule from heaven. They chose a design that makes it impossible to have the same features as their competitors.
@lucas1 said in We don't understand TFS and we don't want to.:
If you don't want to merge someone's work, don't accept their PR.
Right; but locks ensure that the work wasn't done in the first place because the second person stomping over the first person's changes would have been notified "hey you probably shouldn't waste your time working on this file". That's just another way of saying "Git wastes your employees' time."
@lucas1 said in We don't understand TFS and we don't want to.:
Mutual locks aren't needed, PR permissions and code review fix this.
They discard the wasted work, but they don't prevent the wasted work in the first place. File locks do.
@lucas1 said in We don't understand TFS and we don't want to.:
Which is the proper way to address this problem rather than arbitrary like the company I am working for make it difficult to checkin/push your work.
Nobody's going to defend the way your company is using file locking. That's stupid.
But a source control program having optional file locking is not stupid. It's smart. In the worst case, you just ignore the feature exists, and guess what? You're not out anything.
@lucas1 said in We don't understand TFS and we don't want to.:
As for Shelvesets, just push checkout a new branch from your existing working branch and push it to the server.
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". Jesus, people, we've had this discussion on this site like 500,000 times, I'm really sick of it. Please anticipate I'm going to make the same arguments as last time and save me some typing, ok?
@lucas1 said in We don't understand TFS and we don't want to.:
Also you know you have these things called stashes that are locally.
A.k.a. your code's not backed-up at all. Local is useless in a corporate environment. I would be a bad employee if I did this. People who do this are probably in violation of their company's information policy, which probably says something like "all company data should be stored on a backed-up network drive at all times".
@lucas1 said in We don't understand TFS and we don't want to.:
I don't think you really understand Git.
Undoubtedly true, since its usability is garbage. However, I understand enough to know that it's garbage.
@lucas1 said in We don't understand TFS and we don't want to.:
I used to bitch and moan about it until I learned how it work.
Even if I knew exactly how it worked, it'd still be garbage, and I'd still bitch and moan. Because it's garbage.
"Knowing how it works" doesn't magically give it features its competitors lack, or make it usable and discoverable, or even remove the moronic errors it gives you like when you can't switch branches because of a "local change" which turns out to be a fucking space at the end of a text file.
I know how a lot of shitty broken things work. They're still shitty and broken.
-
@lorne-kates From rumours I have heard. This is quite possibly what happened.
"mirages a branch" or whatever, it'll cost 16 hours.
That had me pissing myself laughing.
-
@jbert said in We don't understand TFS and we don't want to.:
Something else Git doesn't have which sometimes annoys my Obsessive-Compulsive side: you can't edit Git comment messages* after the fact, while you can do so in TFVC (at least if you have sufficient permissions).
You might like Fossil. While it technically doesn't allow you to change commit messages, it does let you post corrections and the various UIs pick them up (while also showing the uncorrected version for anyone who is curious enough). Outright nuking history is only really useful when you do something really mega-dumb like committing secret keys or passwords to a repository…
In any case, it does have the downside (for some here, if not for me) of not being currently supported by TFS as a back end.
-
@blakeyrat said in We don't understand TFS and we don't want to.:
Git does not
It doesn't push them to the origin server by default. If someone wanted to do it, it wouldn't be hard to support, but it's much more common to make a new branch instead (because branches are really cheap). Some hosting providers do things with pull requests to make this stuff appear neater, but that's their value-add.
-
@dkf said in We don't understand TFS and we don't want to.:
It doesn't push them to the origin server by default.
It doesn't push them to the origin server at all.
The only way to push a stash to a server is to make it something entirely different from a stash.
If I could push a stash to a server without having to make a commit or giving it a name or giving the branch it's in a name, then I wouldn't say that Git lacks server-side shelvesets, because it'd have something equivalent. Right now it does not.
Not sure why people are having trouble with this.
-
So people don't stomp over other people's changes to a binary file that Git has no clue how to merge.
There is a PR system for a reason. Also worst comes to worst, it is still in source control and it is trivial to find the right version. Binary Dlls should be pulled from another repository and built. Inedo's ProGet actually supply a clean way of doing this.
Git doesn't have to be militantly distributed all the time forever. That's a design decision they chose, not some God-delivered rule from heaven. They chose a design that makes it impossible to have the same features as their competitors.
The PR system makes this unnecessary. As I said the whole mutual locks mechanism doesn't make sense if you have the PR, distributed system.
Right; but locks ensure that the work wasn't done in the first place because the second person stomping over the first person's changes would have been notified "hey you probably shouldn't waste your time working on this file". That's just another way of saying "Git wastes your employees' time.
PR review makes this unnecessary, you normally let another developer review your changes and they accept your PR if it passes code review and also Git will reject anything it can't auto-merge and you have to merge it and update the PR. The PR will be reviewed and accepted or rejected by another developer.
Things should be going through code review and the PR system makes this quite to do.
They discard the wasted work, but they don't prevent the wasted work in the first place. File locks do.
There is no wasted work, the work is code reviewed and the PR is accepted or rejected based on code quality, not being able to merge the changes automatically etc. There is no need for locks because the PR is your "lock".
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". Jesus, people, we've had this discussion on this site like 500,000 times, I'm really sick of it. Please anticipate I'm going to make the same arguments as last time and save me some typing, ok?
Branches get deleted in Git on Merge (not deleted forever in reality, but are deleted in terms of visibility).
"Knowing how it works" doesn't magically give it features its competitors lack.
As mentioned above you don't understand how it works. As mentioned previously I have no problem with TFS, I think it is good. I just think Git is better. I get it you don't like Git, mainly because you don't understand it. There is plenty of information on Git and how to use it correctly. If you don't wish to read that is you lookout and not mine.
I get the feeling that you either don't want to understand or just wanna try to troll. As I said it is you lookout.
branches because of a "local change" which turns out to be a fucking space at the end of a text file.
TFS is far more guilty of this than Git. Again, not knowing what you are on about.
This will be my final reply to you on this on Git VS TFS because you don't seem to understand how Git works and are more intent in having an argument for the sake of it.
EDIT: Clarity.
-
@lucas1 said in We don't understand TFS and we don't want to.:
There is a PR system for a reason. Also worst comes to worst, it is still in source control and it is trivial to find the right version.
By the time you're at this point, the second employee has already wasted their time editing a file they can't possibly ever merge.
I really don't know how else to explain this. The reason you want file locking is so you can prevent people on your team from wasting their time with useless work. PRs don't solve that problem.
@lucas1 said in We don't understand TFS and we don't want to.:
Branches get deleted in Git on Merge (not deleted forever in reality, but are deleted in terms of visibility).
Ok? Not sure how this is relevant to anything at all. What does it have to do with me being forced to type in a junk commit message just to put some code on the server?
@lucas1 said in We don't understand TFS and we don't want to.:
As mentioned above you don't understand how it works.
I admitted to that.
If I took some intensive course and learned how it works, would Git shuddenly magically have file-locking? Or is your argument just that to use Git you should first have Stockholm Syndrome to the extent that you can't even possibly imagine features Git doesn't already possess?
@lucas1 said in We don't understand TFS and we don't want to.:
I get it you don't like Git, mainly because you don't understand it.
Right; but what I don't understand is why you think that my understanding of Git is the key to these features I'm mentioning existing. Basically, you're saying if I read a textbook about it, suddenly every Git user in the world would have access to server-side stashes? Or... what the fuck are you on about?
@lucas1 said in We don't understand TFS and we don't want to.:
I get the feeling that you either don't want to understand or just wanna try to troll.
I'm just calling shitty software shitty. Git is shitty. No trolling involved.
@lucas1 said in We don't understand TFS and we don't want to.:
TFS is far more guilty of this than Git.
I never said otherwise?
"Git has stupid annoying behaviors" is not mutually-exclusive with "TFS has stupid annoying behaviors".
@lucas1 said in We don't understand TFS and we don't want to.:
This will be my final reply to you on this on Git VS TFS because you don't seem to understand how Git works and are more intent in having an argument for the sake of it.
Well then I guess I'll never know how my level of understanding of a product causes the product to gain or lose features. Too bad, I was really curious about that.
-
@blakeyrat said in We don't understand TFS and we don't want to.:
By the time you're at this point, the second employee has already wasted their time editing a file they can't possibly ever merge.
They aren't editing the file they are reviewing the file. Again you are an idiot.
Code Reviews are a good thing.
-
@blakeyrat said in We don't understand TFS and we don't want to.:
I'm just calling shitty software shitty. Git is shitty. No trolling involved.
You are doing the equivalent of slagging off MS Word for being a bad word-processor, while pissing on the keyboard and then getting angry when the keyboard is full of piss and it doesn't work.
-
@lucas1 said in We don't understand TFS and we don't want to.:
They aren't editing the file they are reviewing the file. Again you are an idiot.
Jesus Christ. Try to follow me here:
TFS:
Bob wants to edit the website's header image, which is a PNG.
Bob knows that TFS can't merge PNGs in a reasonable way so he sets the file to "locked".
Alice goes to edit the header image, sees that it's locked, decides to work on something else instead.Git:
Bob wants to edit the website's header image, which is a PNG.
So he does.
Alice wants to edit the website's header image, which is a PNG.
So she does. Nothing tells her Bob's already working on it.
Both Bob and Alice finish their changes and create PRs.
Since the PNG edits can't be merged, either Bob completely wasted his time (his work has to be thrown away) or Alice completely wasted her time.
Bob and Alice, having wasted a week of work, both say, "why the fuck is this shitty company using such a shitty source control product?" In unison. It's a teachable moment.(And of course the real laugh here is that TFS is actually pretty good at merging PNGs. It's only GIt that's utterly hopeless at it.)
@lucas1 said in We don't understand TFS and we don't want to.:
You are doing the equivalent of slagging off MS Word for being a bad word-processor, while pissing on the keyboard and then getting angry when the keyboard is full of piss and it doesn't work.
Fine; I'm pissing on a keyboard. Whatever.
You're claiming that if I knew more about Git, it'd magically gain features it doesn't currently have. That's the thing I'm curious about. What's going on in your head when you type that? Do you really think my personal level of knowledge can affect reality?
-
@blakeyrat said in We don't understand TFS and we don't want to.:
I admitted to that.
Good, I am glad we have found out what you dunno what you are talking about.
As someone that has used both Git and TFS extensively in large organisations and been merge master in some cases. Maybe do us all a favour and listen for once.
-
@blakeyrat said in We don't understand TFS and we don't want to.:
They chose a design that makes it impossible to have the same features as their competitors.
They chose that rule because they didn't see why it was necessary to have it when doing large collaborations (the specific use-case they explicitly wanted to solve). All it means is that Developer A doesn't need to give a
about what Developer B is up to, or vice versa, until the point where one or the other of them is adding their overall changes to the agreed shared state. Which is when they really ought to care anyway; if they're totally isolated from each other, they're not actually working on the same project.Locks are simply unnecessary (for repository consistency; local locks might still be used by editing software) when the system has a way to store the exact state of the file system at a particular time and branch the history at that point. There's no changing the file system without the developer's permission; they can simply elect to see the file as it was before the change or the file as it was after the change. After all, there's no reason why the guy developing the assets for the next major version of the software package should be blocked because someone else is fixing a bug in the assets for the long-term commercial support version of those assets.
In short, your social problems aren't my technical problems. ;)
-
@dkf I think I heard about Fossil on one of the BSD Talk streams of the past.
I didn't understand TFS or Git as well as I do now. I will admit I am ignorant of most of source control systems as I have only worked with these two extensively.
Fossil sounded sensible, but I think it is a little bit too obscure for most people.
I think Git is now the defacto standard for source control and if I were a dev I would learn it before anything else IMHO.
-
@dkf said in We don't understand TFS and we don't want to.:
They chose that rule because they didn't see why it was necessary to have it when doing large collaborations (the specific use-case they explicitly wanted to solve). All it means is that Developer A doesn't need to give a about what Developer B is up to, or vice versa, until the point where one or the other of them is adding their overall changes to the agreed shared state. Which is when they really ought to care anyway; if they're totally isolated from each other, they're not actually working on the same project.
Fine; and there's environments where that's perfectly ok and Git's (features at least) are well-suited for. (It's usability is garbage no matter what.)
The problem is, none of the places where I've been forced to use Git are like that at all. Now normal non-jerkwad developers might think to themselves, "hm, our product was intended for X, but is being used for Y, maybe we should add some features to ensure Y works better so our users aren't being shat on quite so much". But Git developers will never think that, because they're incompetent jerkwads.
@dkf said in We don't understand TFS and we don't want to.:
Locks are simply unnecessary (for repository consistency; local locks might still be used by editing software) when the system has a way to store the exact state of the file system at a particular time and branch the history at that point.
Bullshit. I just laid out a scenario where locks would have saved the company tons of work.
Ok sure they're "unnecessary" in that people didn't actually die because they're missing, but it's not like it's some weirdo useless feature that Microsoft just added to TFS on a lark.
@lucas1 said in We don't understand TFS and we don't want to.:
I think Git is now the defacto standard for source control and if I were a dev I would learn it before anything else IMHO.
What features does it magically gain once you're done learning it? Does it control RC airplanes or something? I'm so curious.
-
@blakeyrat The scenario is bunk, these things don't change that often in a small business and in a large business it is handled by the CMS.
The best argument you might make is things like (but not excluded to)
- glyph-icons - again these don't change often
- binary dlls - use latest stable or whatever version is in package control (again having a dependency manager local for company packages is now trivial).
Again your arguments are mostly what-aboutery scenarios which are easily worked out in reality.
-
@lucas1 said in We don't understand TFS and we don't want to.:
The scenario is bunk, these things don't change that often in a small business and in a large business it is handled by the CMS.
Whether or not it comes up often, Git has no answer for it at all other than throwing away someone's work. TFS does. TFS is superior in that regard.
Planes don't crash down to the runway at 400 mph with no landing gear very often, either. But it's generally a good idea to have a plan just in case one does, instead of just standing around flailing your arms screaming "but it doesn't happen very often!" while your friends and neighbors are burning to death in agony.
@lucas1 said in We don't understand TFS and we don't want to.:
Again your arguments are mostly what-aboutery scenarios which are easily worked out in reality.
Right; by switching to source control software less shitty than Git.
The real thing that bugs me about this conversation is that, despite actually using TFS, you seem to have Git Stockholm Syndrome so badly that it's difficult for you to even imagine scenarios where Git sucks. It's kind of amazing. Especially since Git sucks in almost all scenarios.
-
@blakeyrat said in We don't understand TFS and we don't want to.:
@dkf said in We don't understand TFS and we don't want to.:
Locks are simply unnecessary (for repository consistency; local locks might still be used by editing software) when the system has a way to store the exact state of the file system at a particular time and branch the history at that point.
Bullshit. I just laid out a scenario where locks would have saved the company tons of work.
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.
-
@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.
-
@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.
-
@blakeyrat said in We don't understand TFS and we don't want to.:
Whether or not it comes up often, Git has no answer for it at all other than throwing away someone's work. TFS does. TFS is superior in that regard.
You can always find unrealistic scenarios that breaks a good system.
e.g. You are basically saying the same as this:
If I fill my car up with Petrol (it is a Diesel), It will damage my engine. Therefore Diesel Engines are bad for everything and inherently flawed.
Right; by switching to source control software less shitty than Git.
The real thing that bugs me about this conversation is that, despite actually using TFS, you seem to have Git Stockholm Syndrome so badly that it's difficult for you to even imagine scenarios where Git sucks. It's kind of amazing. Especially since Git sucks in almost all scenarios.Except it doesn't because I it works perfectly fine for me and I don't have any of the imaginary problems that you always seem to dream up.
As I said I know how to use both well, I like Git better. I am working at a place that uses TFS and am not that bothered except the retardery which is a stressed out dev trying to hold back management with some A-class bullshitting.
I used to work with a developer like you. This is how a typical conversation went:
Me - "This old manager of mine said
It is possible to walk to Australia, he was an idiot" (From the UK)
Him - "Well if you do this <INSERT TOTALLY UNREALISTIC SCENARIO> you can".
-
@lucas1 said in We don't understand TFS and we don't want to.:
You can always find unrealistic scenarios that breaks a good system.
e.g. You are basically saying
If I fill my car up with Petrol (it is a Diesel), It will damage my engine. Therefore Diesel Engines are bad for everything and inherently flaw.No the flaw there is that the pumps aren't keyed to physically prevent that from happening. Here in the US, diesel pumps are designed to not fit in gasoline cars, but there's nothing I'm aware of that prevents the problem happening the other way around.
Basically, filling your car is like using Git: there's tons of little landmines you have to avoid because the user experience is shitty. The solution isn't to point and laugh at people who get it wrong, but to fix the user experience.
@lucas1 said in We don't understand TFS and we don't want to.:
Except it doesn't because I it works perfectly fine for me and I don't have any of the imaginary problems that you always seem to dream up.
Good for you? That doesn't make them not-problems.
@lucas1 said in We don't understand TFS and we don't want to.:
As I said I know how to use both well, I like Git better.
Fine; you can prefer whichever you like. What you can't do is come in here and blatantly lie by saying Git has all the features of TFS, which is objectively false.
-
@blakeyrat said in We don't understand TFS and we don't want to.:
No the flaw there is that the pumps aren't keyed to physically prevent that from happening. Here in the US, diesel pumps are designed to not fit in gasoline cars, but there's nothing I'm aware of that prevents the problem happening the other way around.
I am not a fucking idiot. I know that my car uses Diesel. I pick up the Diesel Pump. Doesn't need a special designed fucking nozzle, maybe us English are just that much better than the US in this regard ... Maybe that is why I also know more than you about source control.
Basically, filling your car is like using Git: there's tons of little landmines you have to avoid because the user experience is shitty. The solution isn't to point and laugh at people who get it wrong, but to fix the user experience.
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.
Good for you? That doesn't make them not-problems.
There are plenty of people disagreeing with your assessment, and while I don't like an appeal to popularity. Sometimes it is a good idea to shut the fuck up, take stock and then actually know wtf you are saying. You might have been right the first time and not know the arguments, you might have known the arguments and expressed them poorly and you might have been wrong.
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!
-
@blakeyrat said in We don't understand TFS and we don't want to.:
Ok sure they're "unnecessary" in that people didn't actually die because they're missing, b
I have been agreeing with your posts on this topic, but regred to inform you that the above is incorrect. Because of arguments determining if Bob's changes or Alice's changes would be accepted, the users still saw the old ping, which contained instructions in the image that resulted in their death.
-
@bulb 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.:
Git has nothing equivalent to those "useless ™" server-side shelvesets
It does. Developer branches. And they are more useful, because they can contain multiple changesets.
If you don't have a space where you can push random work in progress on the server (usually
user/<username>/oru/<username>or similar), that's an organisation problem, not a technical one.THANK YOU
bsdtalk194 - Fossil SCM with D. Richard Hipp
