IT/Software career thread: Invert binary trees for dollars.

We switched from TFS to Git a few months ago without knowing exactly what we were getting in....then came the "oh shit, get this project out the door ASAP" crush time. So we got stuck with this wierd hybrid of old-school-TFS way of branching out and git. We keep wasting time figuring out why the fuck things are missing or not merged properly.

Of course, now that we know better, we're pretty much at a point where we would need to nuke the repository and start over with an actual branching/release strategy. On the other hand. getting time to do things properly is a whole beast in itself.

Lendarios said:

So what is the etiquette when your fat ass coworker falls asleep on his chair and starts snoring?

Click to expand...

Ain't your problem.

Listen. If one of the pitfalls of my source control is that I can lose everything why would I ever use that source control product? That's like using an erectile dysfunction pill that has impotence as a side effect

SVN is definitely too light weight for projects with more than one or two devs, but it's awesome for scripts and config files. Plus it's portable. I dump my repos to a portable drive, install svnserv on whatever machine I'm building and have instant repo access.

Cad said:

Not lose everything, just lose your changes. If you don't sync your local workspace in git to the repo often enough and you do.......anything.......to confuse git you will never get it to sync and whatever you did locally will be shit.

Click to expand...

Honestly, I don't know what you're doing here to cause this. The only time I ever had an issue with git, and this was during the learning phase, is switching to a different branch without committing existing changes first. You'll end up carrying those uncommitted changes over to the branch you switched to. I never bothered to learn exactly what you're supposed to do in these situations -- you can definitely bork things up if you don't catch yourself. But, for me, it's become a habit now to always commit changes before switching off to some other branch.

And my complaints earlier wasn't about source control management. It's really about developing against a framework that's a constant moving target. Very frustrating.

Cad said:

Not lose everything, just lose your changes. If you don't sync your local workspace in git to the repo often enough and you do.......anything.......to confuse git you will never get it to sync and whatever you did locally will be shit.

If you follow the script on git and just do basic, change these 4 things and check back in stuff it is easy as pie. Go off script and it's like hand editing binary in vi level difficulty, such BS

Click to expand...

It's easy. Just commit your changes locally and fetch and rebase.

I've used git,.svn, and clear case and git is definitely the easiest to use. Clear case is the fucking worst

agripa said:

I was told today by a director of infrastructure that their change windows are only for making changes and not troubleshooting. What a POS, I hope this company dies in a fire.

Click to expand...

I'm in global change management for a finance company. Is your troubleshooting on resources outside the scope of the changes but still covered by the change window? Could your troubleshooting affect the changes in flight? If not, and the chance is low that the troubleshooting will cause further issues, then I can't see why he'd have a problem with it.

LiquidDeath said:

I'm in global change management for a finance company. Is your troubleshooting on resources outside the scope of the changes but still covered by the change window? Could your troubleshooting affect the changes in flight? If not, and the chance is low that the troubleshooting will cause further issues, then I can't see why he'd have a problem with it.

Click to expand...

This. Change Windows @ large companies are managed very carefully for Financial impact reasons. If a failure occurs then the revert process has to start.

Vinen said:

This. Change Windows @ large companies are managed very carefully for Financial impact reasons. If a failure occurs then the revert process has to start.

Click to expand...

They are also carefully managed because change managers are risk averse by nature and experience. Individual team members tasked with changes are usually less risk averse and don't often take into account the full scope of how their changes, or even minor tinkering, could affect activities up or down stream. Change bureaucracy is usually annoying but often for good reason.

LiquidDeath said:

They are also carefully managed because change managers are risk averse by nature and experience. Individual team members tasked with changes are usually less risk averse and don't often take into account the full scope of how their changes, or even minor tinkering, could affect activities up or down stream. Change bureaucracy is usually annoying but often for good reason.

Click to expand...

I'd say experience is the largest key area. All it takes is one burn to become risk adverse.

Unfortunately, they tend to train the worst people in the DoD. Sending policy people off to a MCSE bootcamp, shit like that.

I probably won't stay too long in defense. Maybe another year or two max and head out. There are smart people here but everything is bogged down by old.technologies and red tape