See https://softwareengineering.stackexchange.com/questions/109817/superior-refusing-to-use-subversion
My question is similar, but here are the main differences in my scenario:
-
We are starting a new project from scratch, using PHP and web tech. There would be no down time in development as we would be adopting it from the beginning, if I have my way.
-
My dev team consists of me, and my boss. We are the "IT" Department of a relatively small firm.
The web app will replace a legacy application with absolutely no source control. Due to variations in geographical legal requirements, the decision was made (before I was hired) to fork the app into 7 completely separate directories for each version. Different developers did different things in different places at different times after that. Patching changes across them, well, I think it could be done better, I guess that's why I'm posting.
My boss's proposal, directly pasted from an email:
Updates should be submitted as packages in the SUBMISSIONS folder. The package should contain all relevant files as well as an
‘UPDATE.NFO’ file that contains a description of the update, a list of
all new files included (with descriptions), and a list of all modified
files with modification details.Update packages should focus on an individual element and not stray from its intended purpose. Code should be designed to be modular and
reusable whenever possible.All submitted packages should be installed in each developer’s test environment soon after submission. Each developer is to review the
new addition and voice any concerns over its installation to the
production environment. A standard package update should be held for
a minimum of 3 business days for this review process before being
loaded into the production environment. High priority updates/fixes
can skip this requirement.
The reason source control was invented is to make all that automatic, right? I suggested subversion, because that's what I used in college. Boss doesn't like subversion because "It makes a mess of the code" (i.e. uses binary magic and is not plainly readable). We did try it one time, but I think trying to use it on windows made weird lower/uppercase errors and we couldn't check out our files. I don't know whether it's only subversion, or all source control products that are objectionable.
So, what kind of argument should I make to my boss? Or is he right, and there could be a danger of losing all our work from some weird bug?
Or am I wrong altogether? Is source control really necessary in my situation? This is our main business-critical software we're talking about, so it will end up huge no doubt. But there's only 2 developers (now).
Additionally, If I can't convince him, would there be any point to me using it only for myself? I am speaking as someone with very limited experience actually using svn; all I really know is checkout and commit. What are the features of source control (may include other products than svn) that would aid in my individual development effort?
Please no "get another job" comments. That's not helpful to the debate.
Best Answer
Don't ask him. Don't tell him. Show him.
Install svn, or git, or whatever you like on some extra machine. Practice using it yourself until you feel comfortable not just using it, but explaining it. If you're going to make him comfortable with your new system, you'll need to be more than comfortable with it yourself. You'll need to be able to help him recover easily when he screws up a merge or checks something into the wrong place.
When you're ready, show him exactly what you're talking about. Show him that it doesn't "make a mess" of anything. Point out that it doesn't just let you retrieve any previous version of your code with ease, it also makes it possible to know exactly what changed between any two versions.
Point out that if anything ever happens to the server (serious bug, virus, hacker, disk crash...) you'll both look like heros if you can instantly reconstruct the necessary version. Point out, too, that you'll look twice as good if you're able to produce any version on demand. Search your old e-mail and compile a list of problems you've had over the past year that you could have avoided with version control.
Give him a cheat sheet that will make it easy for him to use your version control system.
Finally, suggest some options but leave the decision to him. Should you set up your own server, or use one of the many hosted services? Should you use svn, git, or something else? Should you migrate all seven projects to the system, or try it with one or two at first?