But you said to do this
-
@boog said:
From what I've read snoofle say about this guy, I wouldn't put anything past him. Checking in each file one at a time seems well within his stupidity scope.@MiffTheFox said:
What kind of crazy source control won't let you just roll back to an old revision?
I was wondering the same thing; reverting should be easy. CVS, maybe? (Except that would only require a programmatic rollback if files were added/removed; it didn't sound like that was the case.)I could see if maybe other developers had since made changes that they needed to keep - it could be tricky to revert old changes and cherrypick new changes. But it didn't sound like there were a lot of other developers working on that particular third-party tool.
Maybe the guy just made a mess of things when he tried to revert one-by-one?
I'll bet he spent the first day checking out the files individually, the second day making his code changes, and the third checking in each file, one at a time...
-
@Cassidy said:
Yes, that's all well and good, but it doesn't go against my point... which was: Even if there were no bugs, there would still be jobs creating new stuff.Stuff
-
@C-Octothorpe said:
One-by-one or in a single commit, it shouldn't matter. Most (all?) source control systems allow you to revert to a given date.From what I've read snoofle say about this guy, I wouldn't put anything past him. Checking in each file one at a time seems well within his stupidity scope.
I'll bet he spent the first day checking out the files individually, the second day making his code changes, and the third checking in each file, one at a time...
But I do agree, screwing things up so badly that the source control system can't figure out how to revert is likely within his stupidity scope.
-
@Sutherlands said:
Even if there were no bugs, there would still be jobs creating new
FTFYstuffbugs.
-
@boog said:
TFS doesn'tMost (all?) source control systems allow you to revert to a given date.
-
@Sutherlands said:
Yes, that's all well and good, but it doesn't go against my point... which was: Even if there were no bugs, there would still be jobs creating new stuff.
Oh. Okay, my bad - I thought your point was that fixing existing things gets in the way of creating new things.
.. and I guess creating new stuff brings new bugs, change requests, etc...
-
@Sutherlands said:
Ok.@boog said:
TFS doesn'tMost
(all?)source control systems allow you to revert to a given date.
-
@Sutherlands said:
@boog said:
TFS doesn'tMost (all?) source control systems allow you to revert to a given date.
Right, I thought I hallucinated this dialog:
-
@blakeyrat said:
@Sutherlands said:
@boog said:
TFS doesn'tMost (all?) source control systems allow you to revert to a given date.
Right, I thought I hallucinated this dialog:
That looks like a nightmare! The names of all of your files are gone!
-
@boomzilla said:
@blakeyrat said:
@Sutherlands said:
@boog said:
TFS doesn'tMost (all?) source control systems allow you to revert to a given date.
Right, I thought I hallucinated this dialog:
That looks like a nightmare! The names of all of your files are gone!
You know it would save me a lot of screenshotting, cropping, anonymizing, uploading, etc. time if people just wouldn't post easily-refutable bullshit in the first place.
If you're going to post bullshit, at least make it slightly difficult to disprove. Add some challenge.
-
@blakeyrat said:
@boomzilla said:
Since I can't see your picture, can you post instructions on how to do it? The only thing I've found is this: http://msdn.microsoft.com/en-us/library/ms194956(v=vs.80).aspx and it's been how we've doing "rollbacks". Also, could you stop being a douchebag?@blakeyrat said:
You know it would save me a lot of screenshotting, cropping, anonymizing, uploading, etc. time if people just wouldn't post easily-refutable bullshit in the first place.@Sutherlands said:
That looks like a nightmare! The names of all of your files are gone!
Right, I thought I hallucinated this dialog:@boog said:
TFS doesn'tMost (all?) source control systems allow you to revert to a given date.
If you're going to post bullshit, at least make it slightly difficult to disprove. Add some challenge.
-
@Sutherlands said:
Since I can't see your picture, can you post instructions on how to do it?
Why can't you see the picture? There's no referrer limitations or anything on that site... it's my own domain.
Anyway, you just right-click the repository (or whatever point in the folder tree you want), choose "Get Specific Version...", set the version selector to "By Date", then type in the date/time you want.
@Sutherlands said:
The only thing I've found is this: http://msdn.microsoft.com/en-us/library/ms194956(v=vs.80).aspx and it's been how we've doing "rollbacks".
That MSDN entry talks about rolling-back a changeset. That's not what we were talking about. We were talking about pulling the repository as it looked on a particular date, which is different.
You're basically complaining that TFS can't "un-merge" files. Frankly, that seems like a reasonable restriction to me. That's damned hard, I bet a human would fail at it 9 out of 10 times.
@Sutherlands said:
Also, could you stop being a douchebag?
I would argue that the person spreading blatant lies about the features of a product is being more of a douchebag than the person correcting him.
-
@blakeyrat said:
@Sutherlands said:
I'm not Sutherlands, but FWIW, your domain is blocked by my company's web filter.Since I can't see your picture, can you post instructions on how to do it?
Why can't you see the picture? There's no referrer limitations or anything on that site... it's my own domain.
-
@blakeyrat said:
@Sutherlands said:
Because my work doesn't like your domain for some reason. Reason: "Uncategorized"Since I can't see your picture, can you post instructions on how to do it?
Why can't you see the picture? There's no referrer limitations or anything on that site... it's my own domain.@blakeyrat said:
Anyway, you just right-click the repository (or whatever point in the folder tree you want), choose "Get Specific Version...", set the version selector to "By Date", then type in the date/time you want. @Sutherlands said:
Well I guess we were going off of different definitions of "revert".The only thing I've found is this: http://msdn.microsoft.com/en-us/library/ms194956(v=vs.80).aspx and it's been how we've doing "rollbacks".
That MSDN entry talks about rolling-back a changeset. That's not what we were talking about. We were talking about pulling the repository as it looked on a particular date, which is different.@blakeyrat said:
You're basically complaining that TFS can't "un-merge" files. Frankly, that seems like a reasonable restriction to me. That's damned hard, I bet a human would fail at it 9 out of 10 times.
All I, personally, want in this scenario is the ability to delete the latest change.@blakeyrat said:
@Sutherlands said:
"Blatant lies" != "different definitions of the question". I'll agree that most(all?) source control options allow you to retrieve a previous date. They wouldn't be much good if they couldn't. Also, it's not about correcting someone, it's about the tone in which you correct someone.Also, could you stop being a douchebag?
I would argue that the person spreading blatant lies about the features of a product is being more of a douchebag than the person correcting him.
-
@Sutherlands said:
Because my work doesn't like your domain for some reason. Reason: "Uncategorized"
Quit. If they won't treat you like an adult, go someplace that will.
@Sutherlands said:
Well I guess we were going off of different definitions of "revert".
I don't know of any other way to read: "revert to a given date." So you weren't purposefully lying about TFS features. You just have problems reading. Which is good, because I thought it was just my posts people had problems reading, so it's refreshing to know that people don't actually read any of the posts here.
@Sutherlands said:
All I, personally, want in this scenario is the ability to delete the latest change.
That's easy; go to the same dialog, but use "Changeset" instead of "Date". Select the Changeset before the current one. Do your revert, then check it back in. Done.
Or are you complaining that there's not just one big button that does, "revert back one changeset and check it in" as a single operation? Possibly a valid complaint, I'm not sure how useful that button would be and it seems like it could be accident-prone.
@Sutherlands said:
Also, it's not about correcting someone, it's about the tone in which you correct someone.
Ok, what should I have done? "Actually, TFS has that feature, but instead of assuming you're a liar, I'll just assume you're an idiot who can't read!" Would that have been better?
Regardless of why you were wrong, you were wrong. Next time, don't be wrong and I won't correct you, then the correction won't be in the wrong "tone".
-
@blakeyrat said:
Quit.
No. I like my job and don't particularly care about viewing your website. Plus, there's a button to go there anyway if I really wanted to.@blakeyrat said:
@Sutherlands said:
I read "revert" as "return the most current view to a previous changeset." I'm sorry if that offends your delicate English comprehension sensibilities. TFS has no way to return the "current" changeset to the version before a changeset, except checking it out and back in as the old changeset. That's not a "revert," that's a "check it in again." I'm sorry that you think that revert only means "look at something in the past."Well I guess we were going off of different definitions of "revert".
I don't know of any other way to read: "revert to a given date." So you weren't purposefully lying about TFS features. You just have problems reading. Which is good, because I thought it was just my posts people had problems reading, so it's refreshing to know that people don't actually read any of the posts here.
-
@Sutherlands said:
I read "revert" as "return the most current view to a previous changeset."
Yes, but just FYI, there were four words following the word "revert" that were kind of important to the meaning of the sentence. Next time instead of just seeing the word "revert" and deciding to stop reading and write your reply, you might want to read all the way until you get to a period.
BTW, what really pisses me off is these attempts to save face. JUST ADMIT YOU DIDN'T READ IT so we can all move on. You can admit to a mistake just this once. It's not going to kill you.
@Sutherlands said:
That's not a "revert," that's a "check it in again."
I don't understand how the operations differ, except the way they show up in the log perhaps?
-
@blakeyrat said:
@Sutherlands said:
It doesn't matter what it's reverting TO, there's a difference between "revert for your view only" and "revert for everyone's view once they get latest." I wouldn't expect you to understand that, since your solution to most problems is "Quit."I read "revert" as "return the most current view to a previous changeset."
Yes, but just FYI, there were four words following the word "revert" that were kind of important to the meaning of the sentence. Next time instead of just seeing the word "revert" and deciding to stop reading and write your reply, you might want to read all the way until you get to a period.@blakeyrat said:
BTW, what really pisses me off is these attempts to save face. JUST ADMIT YOU DIDN'T READ IT so we can all move on. You can admit to a mistake just this once. It's not going to kill you.
Kettle calling the pot* black?@blakeyrat said:
@Sutherlands said:
RARE BLAKEYRAT ATTEMPTING TO NOT BE PEDANTIC POST! Also, I'm sorry for your lack of imagination.That's not a "revert," that's a "check it in again."
I don't understand how the operations differ, except the way they show up in the log perhaps?
-
@blakeyrat said:
@Sutherlands said:
I'm pretty sure that checking out to an older date is only part of the process you'll need to go through. I primarily use SubVersion, and it can do both "revert" and "check out a specific date/version". If I wanted to use the check out to a specific date feature to accomplish a rollback, the files would end up marked as unchanged and with no changes to commit. I'd have to check out the current version to directory A, date x to directory B, copy all files from directory B to directory A, deal with adds and changes, then commit. Revert and commit is much easier. Also, I've never had a case where a reverse-merge didn't work perfectly, as long as the working copy didn't have any un-committed changes.I read "revert" as "return the most current view to a previous changeset."
Yes, but just FYI, there were four words following the word "revert" that were kind of important to the meaning of the sentence. Next time instead of just seeing the word "revert" and deciding to stop reading and write your reply, you might want to read all the way until you get to a period.BTW, what really pisses me off is these attempts to save face. JUST ADMIT YOU DIDN'T READ IT so we can all move on. You can admit to a mistake just this once. It's not going to kill you. @Sutherlands said:
That's not a "revert," that's a "check it in again."
I don't understand how the operations differ, except the way they show up in the log perhaps?Please tell me if TFS would handle this better. Also, VSS didn't allow multiple working copies of the same project. Did they fix they with TFS?
-
@Jaime said:
TFS doesn't have revert functionality.Please tell me if TFS would handle this better.
But it does allow you to check in a changeset you just got from source control, so it will handle that part better.
-
@blakeyrat said:
You're basically complaining that TFS can't "un-merge" files. Frankly, that seems like a reasonable restriction to me. That's damned hard...
No it isn't. If we're talking about the most recent changes, a reverse merge is the easiest thing you can do.
-
@Jaime said:
If I wanted to use the check out to a specific date feature to accomplish a rollback, the files would end up marked as unchanged and with no changes to commit. I'd have to check out the current version to directory A, date x to directory B, copy all files from directory B to directory A, deal with adds and changes, then commit. Revert and commit is much easier.
Furthermore, if there are any recent changes that you want to keep, simply checking out an old version and committing it will lose all of those changes as well - you'd have to re-add/re-merge them. Reverting (only the revisions you don't want) and committing will avoid that problem, assuming there are no conflicts (in which case you will have to get your hands dirty either way).
-
@boog said:
@blakeyrat said:
You're basically complaining that TFS can't "un-merge" files. Frankly, that seems like a reasonable restriction to me. That's damned hard...
No it isn't. If we're talking about the most recent changes, a reverse merge is the easiest thing you can do.That's a pretty important "if" though. I agree with you, but when I was writing that statement, I didn't include the "if we're talking about the most recent changes" part, which means gasp my sentence was still correct. Reading!
Look, if you have 500 check-ins, and you want to revert check-in 500, that's trivial. We all agree with that. But if you want to revert check-in 469 (without also reverting 470-500), that's virtually impossible. That's what I was saying.
-
@blakeyrat said:
That's a pretty important "if" though. I agree with you, but when I was writing that statement, I didn't include the "if we're talking about the most recent changes" part, which means *gasp* my sentence was still correct. Reading!
I admit it is hard to hit a shrinking target.@blakeyrat said:
Look, if you have 500 check-ins, and you want to revert check-in 500, that's trivial. We all agree with that. But if you want to revert check-in 469 (without also reverting 470-500), that's virtually impossible. That's what I was saying.
Virtually impossible, that is, if any of revisions 470-500 conflict with reverting revision 469. Otherwise, it's cake.
-
@MiffTheFox, @boog: The source control lets us revert. The problem was that it wasn't labeled, so you couldn't just revert the whole tree. You had to find every file the guy committed, figure out the previous version number, and revert that file to that version. For many, many files spread out over the entire source tree. Also, since we caught it quickly, there were no other commits after his, so there were no other changes to worry about undoing.
I just wrote a script to search the entire tree looking for a certain pattern of commit comment and text-delta, then executed a command to get the history of the given file, picked the next older one, and reverted.
I don't mind that he didn't know how to script things. I do mind that he ignored directions. Twice.
Parenthetically, my boss and I talked with the guy to try and explain the problem and show him the right way. He told my boss: I wanted to do it MY way; I don't like other people telling me how to do my job. My boss responded: It's my JOB to tell you what to do and if needed how. If a senior team member asks you to do something in a certain way, you're free to discuss it, but if you are instructed to do something a certain way, you should do it that way. If you want to keep YOUR job, you should be more of a team player. A pissing match ensued with the guy quitting before my boss got mad enough to fire him.
-
@snoofle said:
Parenthetically, my boss and I talked with the guy to try and explain the problem and show him the right way. He told my boss: I wanted to do it MY way; I don't like other people telling me how to do my job. My boss responded: It's my JOB to tell you what to do and if needed how. If a senior team member asks you to do something in a certain way, you're free to discuss it, but if you are instructed to do something a certain way, you should do it that way. If you want to keep YOUR job, you should be more of a team player. A pissing match ensued with the guy quitting before my boss got mad enough to fire him.
I love a happy ending.
-
@snoofle said:
I don't mind that he didn't know how to script things.
Unusual... I've not met that many programmers/developers that didn't know how to script. (I've met several sysadmins that don't, and I've recommended they pick up some scripting language to help with process automation.)
@snoofle said:
He told my boss: "I wanted to do it MY way; I don't like other people telling me how to do my job"
That indicates a number of things for me:
- he can never be (effectively) managed by anyone
- he'll never be receptive to learning new things
- he'll stubbornly continue to repeat his bad practise, resistant to explanations as to why it's not good and rejecting of alternative methods
- you're better off without him
- he can never be (effectively) managed by anyone
-
@snoofle said:
The source control lets us revert. The problem was that it wasn't labeled, so you couldn't just revert the whole tree. You had to find every file the guy committed, figure out the previous version number, and revert that file to that version. For many, many files spread out over the entire source tree.
This does sound an awful lot like CVS, where each file has its own version number. If that's the case, it seems you'd have been able to add labels retroactively:[code]cvs tag -D "1 week ago" before-numbnuts-worked-on-this[/code]
Of course, 1) you may use some other source control I've never heard of, and 2) it doesn't really matter since you had the issue resolved in under 10 minutes anyway.@snoofle said:
If a senior team member asks you to do something in a certain way, you're free to discuss it, but if you are instructed to do something a certain way, you should do it that way.
Indeed. I have no problem with people speaking up if they disagree, even if specifically instructed to do something a certain way. If the person can clearly justify their reasons for doing it another way, smart senior team members will accept that. But to blatantly dismiss his senior's instructions because he doesn't "like other people telling [him] how to do [his] job"? Good riddance.
Somewhat-relevant story: At a previous job, we had a list of coding standards (established long before I started). Such a list can be a good thing and a bad thing. While it encouraged the developers to write clean, secure, less-buggy code, it also had the potential to be limiting. As a result, the list wasn't a hard set of rules, but rather guidelines - if you had a reasonable and clearly-documented justification for breaking a standard, the "QA" folks would often allow it. But if we blatantly broke standards with no explanation and ignored their instructions to adhere to the standards, then they'd simply refuse to put our code in production.
-
@boog said:
Somewhat-relevant story: At a previous job, we had a list of coding standards (established long before I started). Such a list can be a good thing and a bad thing.
I think such lists/policy is a good thing, if used in the way you describe - not a hard and fast law, but guidelines that ensure consistency and maintainability.
I'm also of the opinion that best practice is only that until something better comes along, so any standards should be reviewed periodically to assess their benefits and appropriateness relative to the constantly-changing development landscape.
Each time I've taught programmers, I always mention the importance of following coding standards for their organisation and - if none exist - initiate moves towards formulating a standards policy. Consistency promotes maintainability and all that.
A question for you devs out there: are there any IDEs that contain options to enforce specific behaviour/standards? I don't mean things like implementing interfaces, more things like placements of braces, code comments, banning GOTO, electrocuting the developer if SSDS codebase is detected, etc.
-
@Cassidy said:
That depends on what you mean by "enforce". Visual studio will let you set up coding styles, so that your braces/spaces automagically go to the position you specify as you write, and you can also hit CTRL+K, CTRL+D to format the document to the coding styles. Unfortunately, I don't know of a way to enforce the last 3 things you were asking about.A question for you devs out there: are there any IDEs that contain options to enforce specific behaviour/standards? I don't mean things like implementing interfaces, more things like placements of braces, code comments, banning GOTO, electrocuting the developer if SSDS codebase is detected, etc.
-
@Cassidy said:
A question for you devs out there: are there any IDEs that contain options to enforce specific behaviour/standards? I don't mean things like implementing interfaces, more things like placements of braces, code comments, banning GOTO, electrocuting the developer if SSDS codebase is detected, etc.
For Java, take a look at [url=http://checkstyle.sourceforge.net/]Checkstyle[/url]. It has configurable rules to enforce coding standards, with plugins for various IDEs.
-
@Cassidy said:
A question for you devs out there: are there any IDEs that contain options to enforce specific behaviour/standards? I don't mean things like implementing interfaces, more things like placements of braces, code comments, banning GOTO, electrocuting the developer if SSDS codebase is detected, etc.
There's StyleCop for Visual Studio and SharpDevelop. You have to get used to it (it'll piss you off in the beginning), but by now I have its warnings set to errors and my classes have never been better documented.
-
@heterodox said:
@Cassidy said:
A question for you devs out there: are there any IDEs that contain options to enforce specific behaviour/standards? I don't mean things like implementing interfaces, more things like placements of braces, code comments, banning GOTO, electrocuting the developer if SSDS codebase is detected, etc.
There's StyleCop for Visual Studio and SharpDevelop. You have to get used to it (it'll piss you off in the beginning), but by now I have its warnings set to errors and my classes have never been better documented.
Even better: have a continuous integration server that verifies your source against StyleCop before building it, and fails the build if the StyleCop rules are broken. That way you don't get cowboys disabling StyleCop on their own machines so their shitty code can compile and thus be checked in.
-
I heard of some company (Fujitsu?) doing something like this: all submitted code is run through an algorithm that determines the maintainability of the code[1] and arrives at a figure which - if is above the acceptance threshold - means the developer gets paid. Consequently developers that code faster and can adhere to standards end up with full bellies, coders taking too long (or work at snoofle's workplace) can expect to starve.
[1] Combination of style, structure, percentage of comments. I don't know the full ins and outs, but presumably someone here has experience of similar static analysis tools andcan explain more.
Ta for the replies from others, BTW - interesting to note that there ARE tools out there that can enforce rules and structure.
-
@Cassidy said:
[I]nteresting to note that there ARE tools out there that can enforce rules and structure.
Note that they can also be abused. CheckStyle code review is a thread about such abuse. (Aug '11)
