|
Hahahah! My dad does that!
At every single opportunity that I have, I tell him about benefits of VCS, specifically GIT 
|
|
|
|
|
Depending on the project at hand, IMO git is overrated. I like to keep everything under version control, including documentation. Git is notoriously difficult to use, and sometimes the effort isn't worth the benefits. Especially when working alone on a project, git does not make sense, IMO - git's benefit of cheaply managing branches are not really useful in that case.
|
|
|
|
|
Ohhh... Not sure on that one. If you modify that to say your production build contains commented code, then yes.
|
|
|
|
|
Worse then commenting... You just rename the old code and let it keep compiling!
importantFunction() { ... }
importantFunctionBeforePatch123DontUse() { ... }
|
|
|
|
|
The version control aversion syndrome
|
|
|
|
|
As I work alone, mostly, I don't use any particular program for version control, other than upon reaching a particular milestone I archive the code using WinRar and store on an external drive.
Part of the problem, for me, is that learning and setting up a repository takes more time than I have to devote to it.
|
|
|
|
|
MythicalMe wrote: As I work alone, mostly, I don't use any particular program for version control, other than upon reaching a particular milestone I archive the code using WinRar and store on an external drive.
Version Control is not about achieving milestone. Milestones are just part of it. In version control systems milestones are know as "tags". You will also save a lot of disk space with that as you don't need to create entire project copies with version control systems. They just mark the differences that you can go back to easily.
Version control is really about controlling what was where and when, even for a one person project. You can't possibly remember everything you done and version control is there to help. Sometimes you may break something that you realize only a long time after it was broken. You can see what and how something got broken by comparing the revisions of a particular file.
MythicalMe wrote: Part of the problem, for me, is that learning and setting up a repository takes more time than I have to devote to it.
Take a look at TortoiseSVN[^]. It is really easy to setup a repository with it in two mouse clicks. You don't even need a server for it. You can setup the repository in local file system, external drive, or file share.
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
|
|
|
|
|
I've been programming since 1974. I have 3 terabytes of internal storage and another 3 terabytes available using external docking stations, so disk space is not a problem. As for remembering what I've done... true, but trust me, I know how to read my code and I do document my work reasonably well.
However, as I am always open to changes and new things I will try tortoisesvn.
My original post was mainly at addressing the problem of convincing someone to use a system. When I was first aware of spreadsheet software I never made any headway into using them. I got taught how to use Lotus 1-2-3, by a representative from Lotus, and now I use spreadsheets for a lot of things.
It's like TDD, I read a lot about it and why to use it, but there isn't a lot of how to do TDD. For all I know I have been doing TDD for years, only it is just a different name.
|
|
|
|
|
MythicalMe wrote: but trust me, I know how to read my code and I do document my work reasonably well.
I agree, but you can't document enough to track everything that was done on a file since it was first created. You can't believe how tracking the changes can be useful and better yet, how comparing file version side by side can save tons of time. IN SVN this is called diff, see sample screenshot[^]
This work even for word documents and excel files. Tortoise will show where exactly something got changed and how and when working in teams, by whom.
MythicalMe wrote: However, as I am always open to changes and new things I will try tortoisesvn.
I think you will be pleasantly surprised.
MythicalMe wrote: It's like TDD, I read a lot about it and why to use it, but there isn't a lot of how to do TDD. For all I know I have been doing TDD for years, only it is just a different name.
That's how I feel as well.
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
|
|
|
|
|
I was the same, only much earlier in my hobby than you clearly are, I was hugely surprised at the benefits that I got from switching to VC from project back-ups. Far more than just back-ups and major/minor revision creation. I would also recommend Tortoise though I use TortoiseHg and would in general terms recommend DVCS over SVN style VCS but if you like Tortoise then it should be easy to switch between SVN and Mercurial, I only compared DVCS's in my article on this subject.
M
|
|
|
|
|
Their comeback will be very simply
'If it ain't broke don't fix it'
and they might be right! VCS is not the ideal in every situation, it can make work harder and can be more error prone as people stop thinking! Worse they don't comment about changes in the code as 'oh we can let the version contol tell us' - wrong wrong wrong!
You should also assume you can't trust your VCS and keep manual backups of all release builds or milestone releases. You will sleep easier and possibly keep your job longer!
We use VCS but always use a manual backup for reverting to maintenance changes. We don't acualy fork so thats something we don't have to worry about (lucky us!)
|
|
|
|
|
I tried to do the same thing with a company that I worked for. When I asked one of the guys why he would manually copy directories for some revisions instead of using version control to create a revision history he replied (off topic even) that his code was proprietary because it was better than the rest, and that he didn't need to share any of it with the team, so version control was pointless. I asked him what happened if his house/computer was destroyed and he died. He said he hoped that maybe he could specify with his third party backup who could access the files.
So... I guess:
You might be a Version Control Avoider if.. you are arrogant and ignorant?
I seriously could not believe that kind of response, it didn't even answer my question. It was like he just had that canned and somehow expected all of the people outside of his little bubble to just accept it as valid. I think he has since been forced to use a centralized repository to some degree.
|
|
|
|
|
kdmote wrote: "You know you're a Version Control Avoider if..."
You have foldes like:
\MyProject\Version 1.0
\MyProject\Version 1.1
\MyProject\Version 1.2
\MyProject\Version 1.3
\MyProject\Version 1.4
\MyProject\Version 1.5
\MyProject\Version 1.6
\MyProject\Version 1.7
\MyProject\Version 1.8
....
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
|
|
|
|
|
I would re-phrase via self-deprecation to defuse...
"I knew I was a Version Control Avoider when I ..."
I think most people are amenable to version control as long as someone else goes through all of the pain and suffering of setting it up.
If you can checkout, change, checkin and merge in a relatively painless fashion, then you should have no problem selling it. Merging is where they should see big paybacks!
Here is one for your punchlines:
"...when I had 10 personal copies of the website in various directories and various stages of repair and the only way I was sure which one was active was to check the web server config."
|
|
|
|
|
Hmmm, I haven't read all the responses, so SOMEbody has probably already said this...
you know you're a version control avoider if... YOU'RE FIRED !!
Not very funny, but to the point.
You shouldn't have to EXPLAIN version control to developers.
If they don't use version control,
they shouldn't have been hired as devs in the first place...
|
|
|
|
|
They are actually a team of brilliant scientists who simply have never been formally trained in industry-standard programming techniques. That's why they hired me. I'm just here to help fill in a few gaps.
|
|
|
|
|
brilliant scientist is one thing.
a developer who has AT LEAST read "code complete" is another 
Good luck to ya!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
