|
OriginalGriff wrote: So change it: come up with a unified solution
I really like this positive attitude and goal-oriented re-framing of the problem.
This is truly Engineering Life.
+100 Life Points* to you. May you live long an prosper, Gandalf.
1 Life Point = 32 heart points
1 heart point = 6.72 happy points
1 happy point = 3 cups of coffee
1 cup of coffee = warm lively goodness
In normal play, 100 Life Points would take 7.2 game years#
# 7.2 Game Years = 37.38 Real Life Years.
That means you have just gained an extra 37.38 Real Life Years on your life if you choose to redeem them. 
|
|
|
|
|
What tools are you using? I've been using Microsoft Visual tools for 20 odd years and they've never been better. Sure, we all miss Visual SourceSafe and the web is just an abomination, but there's plenty of scope for *proper* programming still.
Regards,
Rob Philpott.
|
|
|
|
|
I have no complaints about the programming language environment in VS2010/12 - they are great.
I loathe any kind of source control - I have never had any actual cause to use it but spend a lot of time fighting it
|
|
|
|
|
RugbyLeague wrote: I loathe any kind of source control
Uh oh.
If you work at a large place you'll get hit over the head with the Source Control Hammer. They just tell you that you must use it. And many source control packages are confusing and annoying, until you learn the point of how they help you.
But Source Control is a Real Programmer's Best Friend.
Why do I say that?
There are many benefits to using Source Control:
Branching -- changing code without damaging your original trunk code. Then if you don't want to do the change, you just drop the branch, nothing lost.
Tagging -- Oh man, there are so many companies that cannot simply check out the exact version of source that was used to build a particular version that is in production. That's because they didn't Tag. With Source Control you can Tag an exact version, then later when someone says there is a bug in version 3.01, you can go and get that exact source and attempt to reproduce the error even though you are 5 versions past it. It is amazing.
Diffing -- I leave on Friday and by Monday I open source files and wonder "who's been hacking around in here?" Answer: "It was me." I can see all of that because I can do diffs on the code from so many angles that I can tell exactly which source files were changed and by who. It is fantastic.
You must see the tools as something working for you and attempt to learn how they work for you to get all of this.
I used to hate source control too, but if you'll see it as a programmer's helper you will see your life can be so much better.
Good luck.
|
|
|
|
|
I have been trying with source control and I kind of understand why some people like it.
Personally I have never had any benefit from it but lots and lots and lots of trouble. Maybe because I don't understand how to use it.
|
|
|
|
|
You'll see the benefit when your hard drive melts down and you need to get the source of the project you're working on. An off site repository is a must.
If it's not broken, fix it until it is
|
|
|
|
|
previously I backed up to zip files on the server which are subsequently backed up to tape and held off site
|
|
|
|
|
Except that's not SOURCE CONTROL, that's BACKING up - two entirely different things. You should be doing both.
First, assuming you find yourself working in a multi-developer environment... ZIP files does noting for you. How do you reliably get the other developer's changes?
Second, what if you made changes all week and the customer wants you to roll back a portion of it? You can't unless you're zipping every half day. Even then, you lose half a days work.
Third, like someone else mentioned, how would you branch / merge? You can't without source control.
I agree that source control is tedious, kludgy, and a real mess. I STILL don't get TFS on-line, but in VS it works ok. Having said that, I would Never work without it.
If it's not broken, fix it until it is
|
|
|
|
|
I know it isn't source control.
I have always previously worked in a team of one - me.
The customer has never asked me to roll back a portion of it as I always keep the customer in the loop with what I am doing and plan to do.
I have never had a reason to branch/merge
I understand why people use source control - I am venting because I am having to use it.
|
|
|
|
|
RugbyLeague wrote: I am venting because I am having to use it.
Believe me, the day will come that you will say:
"Thank God they made me use it".
Oh, and try to compile and commit the changes every day. The benefit may become more palpable.
Plus, there are source controls that are easier and more intuitive to work than others. Some are a real breeze to work with. Which one are you using?
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson
----
Our heads are round so our thoughts can change direction - Francis Picabia
|
|
|
|
|
Even when I worked in a team of one I found source control essential. It is great when you realise you screwed something up six versions ago and you can go back and see exactly what changes you made.
Yes, I resisted at first. My boss wanted me to use Bazaar. Despite what others may say, I like subversion and I use it for everything.
Backups? Easy. Just back up tthe respository.
I may not last forever but the mess I leave behind certainly will.
|
|
|
|
|
I don't doubt it has it's uses - I just can't think of any time in the last 26 years I have been at this where it would have saved me.
|
|
|
|
|
My source control is just to make a zip-backup with format:
Projekt_name - Timestamp - Brief description of the higlights made that day
With it I have the "Branching" and "Tagging" functionality you describe.
The only one missing is "Diffing" but, since in the PLC-World it is very uncommon that more than a person works in the very same programm, I don't really need it. The only one making changes it's me.
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
very much like my previous method which worked for me since I stopped using 12" mag tapes
|
|
|
|
|
AMEM
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson
----
Our heads are round so our thoughts can change direction - Francis Picabia
|
|
|
|
|
RugbyLeague wrote: I loathe any kind of source control - I have never had any actual cause to use
it
I thought that, too, until I had to uninstall/reinstall a product and discovered the app I had been working on was deleted in the process. I know, why didn't I have it backed up? Because the laptop was on a corporate image and I had limited control over what I could do.
I was able to get a working copy of the DLL, reverse it and rebuild the code... but it was painful.
Now, I use Visual SourceSafe; yes, we are still on VSS.. for now...
Make a change, check it in. If I decide I don't like it, check out a previous version.
|
|
|
|
|
Dude, Source control is your friend. If you don't understand the Source Control they are using try try try,
But seriously take the time to check out other Source Control processes. I have been forced to use GIT, TFS(VSS) in my job.
But for my home projects and my home machine I use TortouseHG/ http://tortoisehg.bitbucket.org/[^]
It just works and it is simple to use and it interfaces with VS Ruby ETC....
Love it.
Seriously Source Control makes you a better programmer because you no longer have to worry about what changes I made or where this rabbit hole I am in is going. It gives you and quick way to get back to the beginning and start down another rabbit hole and takes care of all the overhead. Never mind working with a team. This is just my own mind going down the various trails to see where I might end up.
To err is human to really mess up you need a computer
|
|
|
|
|
I have to use TFS
Previously I would just zip up my dev folder and park it in a rolling folder in the server so it would be backed up. If I found myself going down the wrong path I would just restore the project from the zip file. Live releases would get their own backed up zip file. Easy peasy, lemon squeezy
|
|
|
|
|
How can this be easier than checking in and checking out with very few clicks, a unified and descriptive history?
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson
----
Our heads are round so our thoughts can change direction - Francis Picabia
|
|
|
|
|
Visual SourceSafe RIP my dear friend.
|
|
|
|
|
Actually, I'm still using SourceSafe. I can't stand it. It doesn't handle long lines in a file so it always reports every single minified JS file as having differences in it. It doesn't work on Windows 7/8 properly and certain hacks need to be put in place. Not that it wasn't good in its day though.
|
|
|
|
|
I guess its been about ten years since I last used it. I have a certain respect for its non-branching ethos.
The thing I do remember about it though is lots of very odd files, and the occasional moment when everything would get corrupted completely. That and shouting over the room "after you for Hyperblaster.cpp Dave!"
Regards,
Rob Philpott.
|
|
|
|
|
Not to mention that there was not really any security in the old VSS.
Anyone with commit access could go screw with the repository directly without leaving an audit trail!
|
|
|
|
|
Unfortunately Visual Source Safe is live and well, it just got its name changed to Vault http://sourcegear.com/[^] and i hate it. SVN and/or GIT work so much better...
Rant over.
Eric
|
|
|
|
|
Put a big sign on the wall:
A PROCESS SHOULD ONLY BE CONSIDERED IF:
1: It demonstrably improves products or services from the customer perspective.
2: It demonstrably improves the efficiency of product/service implementation without having a negative effect on point 1.
3: It demonstrably makes the job easier for those implementing the product/service, without having a negative effect on points 1 or 2.
All too many poor and/or inappropriate processes are put in place because they're either fashionable or they appeal to one or more people personally.
If a process, no matter how "in" it is or how appealing it is to your or anyone else's tastes, does not *demonstrably* meet the requirements above, it should be replaced with processes that do.
And keep pounding the word "demonstrably". If someone wants a new process, he has to demonstrate the effects it will have on the company, including all the cons (make sure that any discussions go straight to seeking out the cons, rather than bathing in the glory of the pros).
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
