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.:

    Committing means very different things between SQL SERVER, TFS

    Not really as the commit of the changeset is a SQL transaction commit with TFVC!


  • Java Dev

    @blakeyrat said in We don't understand TFS and we don't want to.:

    @lucas1 said in We don't understand TFS and we don't want to.:

    I disagree, because the concept of a "Workspace" and a "Shelve" is implying that the developer knows what it is like working in a regular traditional workspace i.e. In an out-house, large heavy desk, tools on the wall and shelves above the work space.

    People who work in an office all know what a workspace and shelf is.

    They're a lot less likely to know what a cherry picker is.

    0_1520547008416_43007_700x700.jpg

    Is that what you call them? We call them (literally translated) 'High workers'.



  • @lucas1 said in We don't understand TFS and we don't want to.:

    In your mind, in mine they are equivalent, when we are talking about source control.

    No. And I'm going to write this simply, because this is something you clearly don't understand at all: Some people have never used source control before! They have no source control jargon in their heads. They probably have a little bit of programming jargon in there, if they're going to be trying to use source control. And they, not you are the people who matter. I understand these words. After putting in pointless effort to learn them, that I wouldn't have had to if they used more obvious ones. But why should we make anyone do that?

    Sometimes jargon makes sense, but minimizing it is better for everyone.

    @lucas1 said in We don't understand TFS and we don't want to.:

    I have no idea what you are on about.

    Nothing has ever been more obvious than that.



  • @pleegwat In the UK it is called a mobile elevating platform.



  • @lucas1 said in We don't understand TFS and we don't want to.:

    I already shutup @blakeyrat because he was a moron ny thinking it was a fucking machinery reference.

    Right; it's impossible that I just had a meeting at work I had to attend. I must have momentarily stopped posting because you shut me up.



  • @lucas1 Which is a better name. You just understood my point for a split second right there!



  • @magus said in We don't understand TFS and we don't want to.:
    No. And I'm going to write this simply, because this is something you clearly don't understand at all: Some people have never used source control before! They have no source control jargon in their heads. They probably have a little bit of programming jargon in there, if they're going to be trying to use source control. And they, not you are the people who matter. I understand these words. After putting in pointless effort to learn them, that I wouldn't have had to if they used more obvious ones. But why should we make anyone do that?

    There are these things that employees go through as part of working in a new role. It is referred to as Training.

    McDonalds Train their employees, as someone that worked there (20 years ago now). You have to watch videos, be supervised by another more senior employee while working etc etc.

    I am working at a new company and I am being supervised by another senior employee, asked to read coding standards ...

    It couldn't be that companies expect employees to actually learn how things in the company work and that includes the tooling they are using.

    @magus said in We don't understand TFS and we don't want to.:

    Nothing has ever been more obvious than that.

    Well you have at least learned to use quotes out of context. Maybe in future you will understand that context and Jargon go together and not try to make a lazy gotcha.

    :trollface:


  • ♿ (Parody)

    @magus said in We don't understand TFS and we don't want to.:

    @lucas1 I don't care about how bold your text is. If I want specific things, I want to 'get specific' - sure, an idiom exists, but why use one when you don't have to? What advantage does it gain you? It's just another pathetic attempt to try to look cute.

    Metaphors are how normal humans (blakey may be excused) communicate. What's the equivalent term to cherry picking in TFS? Is there even one? What do you think would be a better word to use? What happens when you pick a different word and then you get a blakeyrant because he's seen the word used differently?

    Again, you might have a legitimate argument here that "cherry pick" was a bad choice but I haven't seen anything to demonstrate that.



  • @blakeyrat You might have been at work, but you weren't working. I post here after work, I don't post here to avoid it.

    Another big difference between you and I.


  • ♿ (Parody)

    @magus 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.:

    Stash ~ Shelveset

    Not the same thing.

    @lucas1 said in We don't understand TFS and we don't want to.:

    Check in ~ Commit

    The former makes far more sense.

    Actually, it does not. When I "check out" a repository, the repository is written to my local disk. When I commit (or you check in code) it does not remove it from my disk.

    And in any case, why are you saying all of this? I will always side with whatever uses more boring, obvious terminology. Like the one before, which I notice you've suddenly gone quiet on.

    It isn't just a matter of having a new dictionary of jargon. It's the quality of the words. Obvious is always better.

    Ah, the masonwheeler fallacy! It's not as obvious as you think it is.



  • @boomzilla said in We don't understand TFS and we don't want to.:

    What's the equivalent term to cherry picking in TFS? Is there even one?

    Dude, I've said it like 5x. It's 'get specific'. Nothing is more clear than that. I wouldn't be pointing it out as a case of this if I didn't have an example.



  • @magus I suspect that like most things it has a nickname among the people that actually use it ... like cherrypicker.

    You use the official name when referring about it to your bosses' boss and then refer to it as a cherry picker to your work mates.

    You don't think ahead of laterally at all. FFS. Most issues are multi-tenanted, especially when we are talking about social norms in a community e.g. Developers or Guys that Do stuff in a Mobile elevation unit or whatever the fuck it is called on gov.uk

    There are De Jure and De Facto names used in every day life for almost everything and they are used at different times dependent on the context. The De Jure name for something that sucks up dust and dirt off my floor is a vacuum cleaner, the De Facto name is a Hoover.

    Do you understand yet, that it isn't as simple as you are trying to make it out as.



  • @lucas1 I suspect that you have a nickname among people you work with, too.


  • ♿ (Parody)

    @magus 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.:

    What's the equivalent term to cherry picking in TFS? Is there even one?

    Dude, I've said it like 5x. It's 'get specific'. Nothing is more clear than that. I wouldn't be pointing it out as a case of this if I didn't have an example.

    Oh, I didn't realize that's what that was supposed to be. I thought you were telling us to be more specific about something. Which is obviously pretty funny when stop and think about it.

    But also, having googled around for tfs "get specific" (which maddeningly enough does not return anything resembling the TFS documentation) I don't think it's at all equivalent. That seems to be git checkout [revision].



  • @magus I do, It is called "Lucas". My real name is Luke.

    Sometimes I get called "Skywalker" if the guy is quite old, the other times it is "Maximus" as I love the movie Gladiator. Not everyone mate is a shitster like yourself you know.



  • @boomzilla If you listen to hip hop ... checking out something made perfect sense ... Just saying.



  • @boomzilla I wouldn't know. I've never looked it up, just used it. For exactly the same things as I've used the same menu option in git in Visual Studio named Cherry Pick.


  • ♿ (Parody)

    @lucas1 said in We don't understand TFS and we don't want to.:

    @boomzilla If you listen to hip hop ... checking out something made perfect sense ... Just saying.

    I don't know what hotels have to do with programming, anyways.



  • @boomzilla

    Beastie Boys - Ch-Check it Out Original Video - RIP MC – 06:44
    — MrZerafia

    I will let the Beastie Boys educate you as they have ultimate treatise on this.


  • ♿ (Parody)

    @magus said in We don't understand TFS and we don't want to.:

    @boomzilla I wouldn't know. I've never looked it up, just used it. For exactly the same things as I've used the same menu option in git in Visual Studio named Cherry Pick.

    From the first line in the description section of the docs:

    Given one or more existing commits, apply the change each one introduces, recording a new commit for each. This requires your working tree to be clean (no modifications from the HEAD commit).

    That's what get specific does with TFS? Because it's not at all like what I saw when I looked around, which just seemed to be checking out a particular revision. It wasn't applying (merging) any changes and wasn't operating on multiple revisions (but maybe you just have to merge them one at a time?).



  • @boomzilla Again they are analogous but not the same.



  • @boomzilla said in We don't understand TFS and we don't want to.:

    That's what get specific does with TFS? Because it's not at all like what I saw when I looked around, which just seemed to be checking out a particular revision. It wasn't applying (merging) any changes and wasn't operating on multiple revisions (but maybe you just have to merge them one at a time?).

    When I used Cherry Pick, I was trying to get a specific version, and it may indeed have gotten them as commits, to my branch. It was an experimental feature that had been rolled back, and I needed to put back in. It was crazily difficult. I had to do it that way though, or merging would merge back in the rollback.

    I haven't used Get Specific in quite a while admittedly, because they've forced us to use git lately, but it essentially makes your local copy that version. I don't know if I've ever tried to do much more than test an old version like that.


  • ♿ (Parody)

    @magus 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.:

    That's what get specific does with TFS? Because it's not at all like what I saw when I looked around, which just seemed to be checking out a particular revision. It wasn't applying (merging) any changes and wasn't operating on multiple revisions (but maybe you just have to merge them one at a time?).

    When I used Cherry Pick, I was trying to get a specific version, and it may indeed have gotten them as commits, to my branch. It was an experimental feature that had been rolled back, and I needed to put back in. It was crazily difficult. I had to do it that way though, or merging would merge back in the rollback.

    Yes, those sorts of merges are a pain. I know that in svn you just add arguments to your merge command (and possibly have to do it multiple times if you're not merging in consecutive commits).

    I haven't used Get Specific in quite a while admittedly, because they've forced us to use git lately, but it essentially makes your local copy that version. I don't know if I've ever tried to do much more than test an old version like that.

    Right. Completely different action.



  • @boomzilla And yet if I were to merge from that version, in TFS, it wouldn't have rolled back my work. So functionally, it is more like cherry picking.



  • @magus No it isn't. In TFS everything is always moving forward.

    In Git, you can amend, rebase etc.



  • @lucas1 said in We don't understand TFS and we don't want to.:

    @magus No it isn't. In TFS everything is always moving forward.

    In Git, you can amend, rebase etc.

    Which is completely destructive (the Git approach) to having a robust/reliable/auditable trail. If something happened, it happened.



  • @thecpuwizard Accept it isn't because the branches are remote and then you make all your changes look the same once they do up to the remote. Your local commits aren't that important in the grand scheme of things, it is only important to you.

    Who gives a fuck what happens when I am devving locally? It matters only when it gets to everyone else.

    It almost as if you didn't know what you were talking about.



  • @lucas1 said in We don't understand TFS and we don't want to.:

    @thecpuwizard Accept it isn't because the branches are remote and then you make all your changes look the same once they do up to the remote. Your local commits aren't that important in the grand scheme of things, it is only important to you.

    Who gives a fuck what happens when I am devving locally? It matters only when it gets to everyone else.

    It almost as if you didn't know what you were talking about.

    It does matter. Isolation (rather than real-time collaboration) is the root cause of the majority of problems.

    Let's assume a developer doers something (locally), an hour later they realize that the work was wrong and have to re-do it. This hour could have been potentially saved.

    Or, one developer is doing something locally that will impact another developer. However the other developer is not aware of the details of what is being done. This will increase costs because of additional work.

    If you have a customer, then they care because they want maximum ROI. If you are an employee (or contractor, etc.) then your boss cares. Only if you are doing something on your own, does it not have an impact on others.



  • @thecpuwizard That why there is CI/CD builds.

    You are complaining about a project management problem rather than developer problem. You are also pretending that people don't talk to one another. If locks are on, you are going to be working with no more than 5 or 6 devs.

    None of what you said is a source control problem. It is a project management problem.

    Let's assume a developer doers something (locally), an hour later they realize that the work was wrong and have to re-do it. This hour could have been potentially saved.

    LOL, how does having centrally controlled repository solve this? It doesn't

    I could do a load of work, decide it is wrong and then do an undo in VS. What are you on about?



  • @thecpuwizard said in We don't understand TFS and we don't want to.:

    If you have a customer, then they care because they want maximum ROI. If you are an employee (or contractor, etc.) then your boss cares. Only if you are doing something on your own, does it not have an impact on others.

    Sorry when I am working on my own stuff I actually care more as my free time was kinda short until recently.



  • @lucas1 said in We don't understand TFS and we don't want to.:

    LOL, how does having centrally controlled repository solve this? It doesn't
    I could do a load of work, decide it is wrong and then do an undo in VS. What are you on about?

    This is more about the amount of work done before it is integrated (including a build with validation tests). As I have indicated before, when this is the goal, each developer ever 10-45 minutes is typical. For a team of 9, this can mean 50 builds per hour (though 25 is about typical)



  • @thecpuwizard So? That should be accounted in the project plan, pretending things always work perfectly is why projects are delivered "late".

    Merging is something you do as a developer when working with others.

    I suggest you watch this:

    To be Honest... • Liz Keogh • GOTO 2012 – 48:11
    — GOTO Conferences

    You and @blakeyrat seems to work in this world where you don't push back against management effectively when there is something unrealistic going on, and pretend everything is about fucking metrics all the time. The business charges 10x what they pay for you to the client. If you are a bit longer on a job realistically it isn't a big deal unless the business is on the knife edge.

    Also 45 minutes for a merge ... Comon. I have done 500+ file merges in TFS from 15 developers got it right first time (because I am disciplined when I do this and I work like a merge robot) and I was done in an hour. That was an exception circumstance. 10 minutes max unless it is a difficult merge.

    Also you should be updating your stuff regularly anyway. Only fucking morons work for 2 or 3 weeks and then merge back from dev.



  • @lucas1 said in We don't understand TFS and we don't want to.:

    You and @blakeyrat seems to work in this world where you don't push back against management effectively when there is something unrealistic going on, and pretend everything is about fucking metrics all the time. The business charges 10x what they pay for you to the client. If you are a bit longer on a job realistically it isn't a big deal unless the business is on the knife edge.

    Clearly you miss things. There is no management for me to push back against. I have been an independent for quite some time (most likely more years than the median age of members here).

    Also 45 minutes for a merge ... Comon. I have done 500+ file merges in TFS from 15 developers got it right first time (because I am disciplined when I do this and I work like a merge robot) and I was done in an hour. That was an exception circumstance. 10 minutes max unless it is a difficult merge.

    Where did you pull that from?

    Also you should be updating your stuff regularly anyway. Only fucking morons work for 2 or 3 weeks and then merge back from dev.

    Again, where did you get that from?


  • Garbage Person

    @blakeyrat said in We don't understand TFS and we don't want to.:

    Have I said anything about Git in this thread that's objectively untrue? If so, point it out.

    Sure, since you asked:

    @blakeyrat said in We don't understand TFS and we don't want to.:

    and the names become permanent even if they're just shit like "checking in unfinished because I'm about to miss the bus".


  • Garbage Person

    @magus said in We don't understand TFS and we don't want to.:

    'Commit' makes no sense. When does anyone use 'committing some work' unless they're using git?

    Also used by Mercurial, Bazaar, can't be bothered to check others.


  • Discourse touched me in a no-no place

    @boomzilla said in We don't understand TFS and we don't want to.:

    Don't use a GUI client. They all suck.

    The Git client in Eclipse is mostly OK (provided you remember to use the History view as well) and covers 99.99% of all operations you actually do, but I've never liked Eclipse's merging tool and so I do complex merges by hand. (I've done that for a long time anyway, so it really isn't that big a problem for me.) OTOH, I've had my colleagues who use PyCharm complain a lot about the merging tool there too, so I'm guessing that diffs and merges are where most GUI tools for VCSs could be better anyway. (It's also technically not Git's fault; most of the same tools are used when you use SVN.)


  • Discourse touched me in a no-no place

    @magus said in We don't understand TFS and we don't want to.:

    But not many

    Or you are just so used to them that you don't see them any more. That happens…


  • Discourse touched me in a no-no place

    @magus said in We don't understand TFS and we don't want to.:

    'Commit' makes no sense.

    It's been around since CVS, which is one of the oldest non-local VCSs there is. (Older VCSs only really worked in distributed mode at all if everything was on a shared filesystem, which really sucked.)



  • @greybeard "It's source control jargon" is not a valid response to "this jargon is pointless and we shouldn't have it"

    I don't care how long ago someone came up with a bad idea if it's a bad idea.


  • Notification Spam Recipient

    @lucas1 said in We don't understand TFS and we don't want to.:

    @pleegwat In the UK it is called a mobile elevating platform.

    Not a coach lift?



  • @dkf said in We don't understand TFS and we don't want to.:

    Or you are just so used to them that you don't see them any more. That happens…

    It has to be able to happen, or not a single person would defend git! Honestly, from the sounds of it even svn does a better job, by saying the sane words for things and then adding the dumb source control jargon versions in parentheses, if @Greybeard 's post is to be believed.


  • Garbage Person

    @blakeyrat said in We don't understand TFS and we don't want to.:

    @greybeard So far the way to solve this problem is:

    • Fast-forward (I have a button like that on my DVD player)
    • Amend
    • Soft Reset (which I guess is like a soft-boiled egg, but a reset?)
    • Cherry-pick (Why cherries? Why picking? What does this even mean?)

    So it's great that Git is so usable and discoverable. There's only 4 ways of doing this task, three of them have nonsense gibberish names. Good jorb Git developers.

    There are two steps that have to be performed: first pulling the commit from the temporary branch into the "permanent" branch, then making the temporary commit disappear from history. I'd given two alternatives for each.

    For the first step, you'd usually just merge the temporary branch. But if you had already moved on from its immediate ancestor, you'd probably be better off doing a cherry-pick than having to deal with an extra merge commit in the second step.

    (As others have pointed out, "cherry-pick" is a common English verb. Google gives the intended meaning as its first definition.)

    For the second, you could do a soft reset, which moves the branch to another point in history while leaving the working space unchanged. It's basically the reverse of the commit operation. (A hard reset moves the branch to another point in history, changing the working space to the state at that point.) Or you could just not bother and make your next commit an amending commit.


  • Discourse touched me in a no-no place

    @magus said in We don't understand TFS and we don't want to.:

    Honestly, from the sounds of it even svn does a better job

    Of naming things? Yes. Git's well known to be weird there. But some of the terms you chose to pick on were the not weird parts of git's naming scheme. (For contrast, the whole business with “fetch” vs “pull” still pisses me off when I think about it.)


  • Garbage Person

    @magus said in We don't understand TFS and we don't want to.:

    @greybeard "It's source control jargon" is not a valid response to "this jargon is pointless and we shouldn't have it"

    It is a valid response to "not used unless using git".



  • @dkf My whole point is that every time git could use a good word, it uses some random other one. Even for simple things. I've never claimed to have mentioned all of them, just ones where there is something demonstrably better used elsewhere.


  • Considered Harmful

    @magus Yes, and said point has been consistently countered. Not sure where restating it will get you.


  • Notification Spam Recipient

    @thecpuwizard said in We don't understand TFS and we don't want to.:

    For a team of 9, this can mean 50 builds per hour (though 25 is about typical)

    :rofl: I wish we could have that many builds per hour. At present, if we pull out the safety blocks, it takes about 15 minutes to do an iterative (i.e. not clean) build. And that's on the specialized machine I purpose-built with specific parts to optimize it, such that it's outperforming the server-grade machine that was built (not by me), which typically does it in 40 minutes (:angry:). Semi-safe build mode gets 25 minutes (95 minutes on the server).

    Good times, good times...


  • kills Dumbledore

    @lucas1 said in We don't understand TFS and we don't want to.:

    Another big difference between you and I.

    You and me*


  • kills Dumbledore

    @boomzilla said in We don't understand TFS and we don't want to.:

    That's what get specific does with TFS?

    Hard to tell since you quoted some Git documentation and apparently expected people to understand it



  • @cursorkeys said in We don't understand TFS and we don't want to.:

    @lorne-kates said in We don't understand TFS and we don't want to.:

    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?!?

    It's similar over here, the universal scheme is:

    Diesel: Big nozzle, BLACK colour handle.
    Unleaded: Small nozzle, GREEN colour for normal octane/BLUE colour for high octane.

    Modern cars seem to have very fancy petrol holes now, for emissions control purposes, so I'm guessing even though an unleaded nozzle is smaller than a diesel nozzle the valving wouldn't open unless it's the correct diameter. A WAG though as I've never tried it.
    Proper lorries get even bigger diesel nozzles, as I found when I tried to refill a box van from a lorry pump as all the other pumps were in use.

    I find it rather silly that the diesel port is the one where you can physically put a gasoline nossle in, because diesel engines more or less completely self destruct when run on gasoline, whereas a gasoline engine just runs poorly and nothing breaks. Sure, it may get so bad that they do not run, but that is easily fixed by just mixing more gasoline into the diesel.
    They got the sizing of the nozzles the wrong way around imho.


Log in to reply