9

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.

Improve this question
22
  • 25
    'And please no "Get another job" comments.' Why not? Your boss is doomed.
    – S.Lott
    Dec 3, 2011 at 3:56
  • 9
    Even if you can't convince him, it's still useful to use it privately for yourself. So you can freely edit your files without fear. You have a bunch of "save points" for the files you work on. Even if you have to have SVN on your local box... better than nothing at all.
    – Lord Tydus
    Dec 3, 2011 at 3:58
  • 10
    @S.Lott, I think the OP has the right to specify the bounds of the question. "Get another job" is not feasible, for instance, if the OP lives in a small country and his/her father-/mother-in-law is the boss of a job in which the OP is paid double or triple what they're worth in the open market. In short, it's not part of the question.
    – Dan Rosenstark
    Dec 3, 2011 at 4:06
  • 8
    @S.Lott I, on the other hand, think that the OP is being silly in trying to specify the bounds on the answer.... Well, the specific bound is not silly at all. Career advice is off topic, and although an answer that would answer the question and offer career advice is perfectly fine by me, I don't think it's silly for OP to specify that (s)he doesn't care for career advice.
    – yannis
    Dec 3, 2011 at 8:53
  • 9
    @S.Lott What I do find silly on the other hand, is career advice in itself, especially when it's "look for another job". There are so many unknown variables, that I find it impossible to take any such advice seriously.
    – yannis
    Dec 3, 2011 at 8:56

5 Answers 5

Reset to default
35

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?

Improve this answer
4
  • 9
    +1 for "don't tell, show (after practice)"
    – Javier
    Dec 3, 2011 at 19:13
  • 2
    But as someone said, DO use it for your own copy
    – 0fnt
    Jun 11, 2015 at 1:59
  • 3
    +1 for 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.
    – Daenyth
    Jun 11, 2015 at 16:08
  • Additionally, showing might be easier if there's something to show. I'd advise to use something with a GUI, like e.g. SourceTree for git. That way it looks way less intimidating, it's easier to learn, nobody has to fear messing up the whole system with a little typo and it pretty much already is a graphical version of the cheat sheet you mention.
    – R. Schmitz
    Feb 27, 2019 at 15:01
28

Benefits of source control go far beyond allowing multiple developers to work on a single piece of code. Eric Sink, the founder of SourceGear, lists a few compelling reasons to use source control as a sole developer:

- It's an undo mechanism.
- It's a historical archive.
- It's a reference point for diff.
- It's a backup.
- It's a journal of my progress. 
- It's a server.

Eric also happens to have a very nice beginners' Source Control How-to. There is a free online Mercurial tutorial available by Joel Spolsky, Mercurial is a popular distributed version control system.

As the next step I suggest you to start using source control locally on your machine, as a sole developer. Very soon your boss will notice that you're capable of sheer magic, like telling within minutes, if not seconds, how far back a super-critical bug goes and then you would tell him precisely which customer accounts were affected and need fixing before all hell breaks loose. Or being able to undo any changes CEO disapproves of super fast.

And finally before you try to convince your boss you may want to delve into the topic of objection-handling. It's 101 of sales.

If unsuccessful - move on as soon as practically possible, not much point in wasting your time tilting at windmills.

Improve this answer
2
  • 1
    +1 for the Eric Sink article. +1 for suggesting hg. git is all the rage but the question clearly states that op is a beginner in source control and hg is a little bit easier to get into than git. +1 for the hg tutorial. +1 for providing a sales oriented reference, that's how you best deal with Pointy-haired Bosses (-0.5 for that being a google search link). +1 for the Don Quixote reference. This is the kind of answer that makes me want to create duplicate accounts so I can upvote more than once.
    – yannis
    Dec 3, 2011 at 5:29
  • 1
    This answer basically says it all. Just one more reason why you should use source control on your own: if and when you do move on, having had some experience with source control will look good on your resume. Not having any such experience will not look good.
    – Mike Nakis
    Dec 3, 2011 at 7:16
10

Yes, using source control, even if only for you, is totally worthwhile. Git, for instance, works really well for a standalone developer and allows you to do things such as branch and merge (with the lowest possible cost) and version your changes as you go.

SVN - or any version control system, really - allows you to do this too, but merging is a bit more problematic.

Improve this answer
5
  • I agree with the use of Git. I use it for projects, even if I'm the ONLY developer.
    – DanO
    Dec 3, 2011 at 5:11
  • I'm starting to as well. I wouldn't with SVN...but with Git, it's so easy to create and manage a repo without even dealing with a server, that it's getting harder to justify not saying git init the second you start working on something.
    – cHao
    Jun 8, 2013 at 0:42
  • without the right .gitignore a git repo is basically useless. That's the only thing that you have to have in place aside from git init
    – Dan Rosenstark
    Sep 18, 2013 at 16:26
  • "but merging is a bit more problematic" - if OP only uses it himself, there's not gonna be a lot of merging, is there? Merging back his own feature branch into his own master maybe, but any code he receives from his boss would rather go in a new commit, no? I have no experience with SVN though, only git.
    – R. Schmitz
    Feb 27, 2019 at 14:48
  • 1
    “There’s not gonna be a lot of merging” until there is. Any project, even if it’s a hobby project, will eventually require the dev team (which could be one person) to work on two things at once. Then you have to merge, and at some point you will encounter merge conflicts.
    – Dan Rosenstark
    Mar 2, 2019 at 13:23
5

If I can't convince him, would there be any point to me using it only for myself?

Yes. There's benefit to using it just for yourself. You get change history so you can see what's different.

No. There's no benefit because your boss has doomed your project to lots of pointless rework because they fouled things up.

Improve this answer
1
  • It's not just that you can see what's different, you can switch between new version and any old version within two seconds.
    – gnasher729
    Sep 7, 2017 at 23:42
3

I highly recommend as mentioned before the use of git, the reason #1 is because any VCS is a safety net in case of disaster. Look for the “In case of fire: git commit, git push, leave the building” sticker. The code may be stored somewhere else, but no in a laptop that can break down, be stolen or whatever... even a local network server is not the safest place for something as valuable as code.

Number 2. Traceability of changes, who did what, when, etc... Merges, Undo. Number 3. Diff the magical tool for #2 and many more cases. Number 4. Branches Number 5. Tagging versions, releases, etc..

You may find more information about one of the most common git workflows here: https://nvie.com/posts/a-successful-git-branching-model/

I know that using git can be intimidating at first, but it’s a good investment for a skill, and a must have for any development team.

About your issue with text case, avoid using Tortoise, I know most people use it as a GUI for git, as it was very common for SVN, so it may be first choice, instead use command line, or a another GUI like github desktop or the SourceTree from Atlasian.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.