14

What are some key ways of getting your team involved in using version control during development, web development or otherwise?

I refuse to work without it, which means anyone involved in the project must also use it. It's just good practice.

GUIs like Tower have helped, but the concept of it is either met with anger ('not my job!' kinda attitude), timidness, or just straight up not using it (using FTP instead, circumventing version control for say, dev or deployment).

Edit: I should have clarified a little that I don't just mean images/PSDs.

Improve this question
7
  • 11
    Make it EASY to use...
    – user1249
    Feb 4, 2011 at 18:34
  • 1
    I find that Git is pretty easy once you spend a few days with it, and have a consensus on how development should go.. it's still been a bigger hurdle for others.
    – Kevin
    Feb 4, 2011 at 18:35
  • 2
    One bit to remember is that version control and backup sometimes meld (while vastly different) and to a designer with binary data; backing up may already be the norm and therefore understanding what he or she is gaining needs to be understood.
    – Aaron McIver
    Feb 4, 2011 at 18:36
  • 1
    @Kevin: What's easy, obvious, and intuitive to a programmer isn't necessarily anything of the sort to other people, even intelligent and creative other people.
    – David Thornley
    Feb 4, 2011 at 18:48
  • 1
    Get engaged with a designer then engage her privately into versioning control. :)
    – user8685
    Feb 4, 2011 at 18:57

7 Answers 7

Reset to default
12

I work on a team of both developers and designers and we all use version control. For the designers, it sucks.

File sharing/backup does always equal Version Control

When you say:

I refuse to work without it, which means anyone involved in the project must also use it. It's just good practice.

You need to be aware of the pitfalls of using version control with binary data:

  • Overwriting: If two designers are working on the same file, the second one to commit will overwrite the first's changes as the current version. The only way to prevent this is locking or constant communication about who is doing what to which file, both of which can hamper their team's workflow.
  • Merging: Tool-assisted merging is non-existent in binary data. Manual merging is painful and prone to huge amounts of errors.

  • Repository bloating: VC systems store only changed lines for text files. This is not possible with binary data, since the whole file will look different to the VC system. This means that while 20 versions of 10KB text file may only take up 20KB, 20 versions of a 1MB file will probably take up closer to 20MB. A moderate-sized design team can easily generate many revisions on dozens of binary files. Your IT department may soon hate you for the storage requirements and possibly even increased memory/CPU your VC server will have.

    You and other developers may also soon hate how long checkouts or updates may take unless you've set up a very good repository organization to avoid the binary files.

  • Reduced benefit: Your designers will rarely, if ever, go back to previous versions of binary files, because 1) no easy way to check a past version's contents 2) no easy way to merge it anyway, and most importantly, 3) they don't work that way -- they are used to building alternate versions of some graphic that may still be useful into the production files themselves.

For your code, you should absolutely be using VC and you are right to demand it.

But you need to check the assumption that that means everyone must also be using it, as well as whether it's even good practice for designers (though backup is). You should store final graphic assets required by your web site/application in your VC, but for production files, it may not be the right solution.

Improve this answer
10
  • Regarding the "repository bloat": you can try to work around that with the right file formats. Documentation stored in a document markup language format and graphics stored in a graphics markup language format instead of the equivalent binary formats can help a lot. Of course the viability of this depends on the project in question and the willingness and competence of the involved people. ;)
    – Baelnorn
    Feb 4, 2011 at 19:53
  • 5
    Overwriting doesn't happen on VCSs worth anything. What happens is that you have two versions of the same file. Yes, the HEAD of the repository will have the last save; but the other designer's work is not lost like it would be on a shared hard drive. I think that is an important distinction.
    – Berin Loritsch
    Feb 4, 2011 at 20:01
  • 2
    @Berin: That's true, but one of the benefits of modern VCS is that two people can work on the same thing at the same time and a lot of the reconciliation work is automatic. However, with a binary file where there is no meaningful merge process, that is not possible. Additionally, the head of the repository is the one that people will think of as "real".
    – jprete
    Feb 4, 2011 at 20:17
  • 1
    As the lifecycle for source code and design documentation differs, make sure to use seprarate repositories for them. I don't agree that repositories suck for designers; most time is spent thinking and modelling, not making lots of small changes to documents. We also make it a rule to disallow automatic merging (on all files stored in the repositories) and therefore have mandatory file locking for edits. Combined with good team communication this prevents a lot of the drawbacks you mention.
    – rsp
    Feb 4, 2011 at 20:43
  • 1
    You're quite wrong, e.g.: Overwriting - this in not a problem of version control, on the opposite, it helps you to detect it. VC systems store only changed lines for text files. - False for git.
    – maaartinus
    Mar 12, 2011 at 10:34
5

The way to approach this is to setup a build system (like Hudson) which uses the version control system to retrieve the build sources and make it a project rule that only artefacts that are a delivered by the build system are going to the test team and eventually deployed at the customer site.

Make it very clear that as far as the project process is concerned anything not coming from the build is private to the developers only; as long as someones' work is not accepted into the build, it might as well not exist.

Improve this answer
4

I refuse to work without it, which means anyone involved in the project must also use it. It's just good practice.

That's a GREAT attitude, right up there with 'not my job!' :-)

The best way of getting buy-in is using something like TortoiseGit or TortoiseSVN to integrate version control into Explorer (assuming Windows). It takes time to see real benefit if you're not used to the version control paradigm. Tortoise at least makes it easy to work with VCS with the mouse. A simple "Right Click -> Checkin" is all it takes.

For this reason, I've been looking to implement transparent version control in TortoiseGit on every file close. If you give someone a branch to work on, and then every write/close becomes a commit operation, then at some point you as the developer can merge their branch without worrying about the consistency of the entire repository, and they can get on with the business of doing what they do without having to know about version control.

I have this same problem with a huge set of audit documents that I can't get people to version control, so we have 50 versions of the same document floating around that are all subtly different.

Improve this answer
2

Illustrate the advantages:

  • Show them how they can save time by allowing everyone to share work and access to a central location.
  • Show them how it allows designers to work on different parts of the project at the same time and merge it back together.
  • Show them how they can tag and build older version of an application for testing or troubleshooting.
  • Show them how they can mess around with a design for experimentation and then refresh the project and not keep changes if they don't want.
  • Show them how they can see what has happened over time.
Improve this answer
4
  • 1
    -1 This was about engaging non-programmers; the list appears geared at a programmer. If you modify your answer I will certainly remove the down vote...
    – Aaron McIver
    Feb 4, 2011 at 19:00
  • 1
    I think you missed the "for non-programmers" part. All the tasks you mentioned are programmer tasks.
    – Erik Funkenbusch
    Feb 4, 2011 at 19:02
  • Sorry, I just read the question, not the title. I will edit the answer.
    – jzd
    Feb 4, 2011 at 19:04
  • 1 Removed...
    – Aaron McIver
    Feb 4, 2011 at 19:27
1

"Not my job" about version control is a sane attitude from a non-programmer.

Build a version control system as simple and invisible as Dropbox is for syncing or Time Machine for backup.

It should just work. No checkout, no commit. Just put the files in the project folder.

Improve this answer
1

I've been using tortoiseHG / mercurial with the new website lady, no problems there. Having no checkouts makes it super simple and puts all the pressure on the person who actually has to make sure the files are synced up. It doesn't even seem like "one more thing to do", it's just, "ok I'm going to demo the website so I've got to ask Peter to resync the changes." and that's no problem.

I had no experience with mercurial before, we use VSS and I would never have wished that on anyone for website source control. I tried it once and I wouldn't blame anyone for not wanting to use it then.

Improve this answer
0

I would say use of of tortoise* clones, it is the simpler it get. Or integrate the version control, in the IDE or whatever.

Improve this answer

Your Answer

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

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