Effective workflow to allow designers access to portion of SVN repository

Question

We have a team of developers and a team of designers. Let me be very clear. The developers are NOT artists and the designers are NOT all that code-savvy.

The developers work on a web application in an SVN repository locally on their machine. We have Windows 2003 workstations which allow each developer to host each website in IIS for debugging purposes. We use TortoiseSVN and Visual Studio with VisualSVN.

The developer's function is to get a new feature functional and working, and then a designer needs to go in and make changes to pages, skins, css, etc. in order to make it pretty, but the changes they make need to be committed back to the repository so that they can be viewed by the developers and not overwritten.

Having each designer have their own IIS server to play around with isn't tenable from a support perspective. The best solution we can come up with currently is to have a design server set up with an independent, shared checkout of the website portion of the SVN repository, and allow all designers to make changes to this site via a UNC share and then commit their changes using TortoiseSVN alone. Then the developers will update to receive these changes to publish to Test and eventually Live.

This seems mostly workable - the biggest problem is that the designers have to be careful not to step over each other and commit only their changes.

Are there other problems I'm not thinking about?

Has anyone else come up with a better solution for this type of workflow?

(I struggled with tags on this one, any help retagging would be greatly appreciated.)

Answer 1

Unless I've missed something in your description you should be able to achieve this using branches.

You haven't gone into too great detail on how you currently branch for feature development/release, so I'll assume for the sake of my example that the developers once they've completed their feature have merged it back to the trunk.

Once this has occurred the trunk should be branched and the designers should commit their changes to this branch.

When they've finished the developers can review all the changes and merge back what is necessary to the trunk for release.

If you wanted to ensure nothing got accidentally committed back by a designer, you could also restrict their write access to only the branch path in the repository.

Answer 2

I don't see how you will be able to get a better scheme than the one you mentioned if you don't relax the 'at most one IIS server' constraint. Isn't it possible to use virtual machines so that each designer can get his own server? All those machines could share the same configuration file. Then designers would not have to worry about each other's changes...

Answer 3

Are the designers using Visual Studio? If so then you can use the embedded web server that comes with VS that way you do not need IIS at all. That is how I do all of my development.

If you use the branching features of Subversion then each designer can create their own branch and work within that until they feel comfortable merging to trunk or whatever version branch the rest of the developers are working on.

Keeping everyone as isolated as possible tends to keep things moving along smoother. That means no shared web server. This is really the methodology that Subversion was built for anyway.

One strategy that I like is to a use a trunk cop. Assign one of your developers the job of managing the trunk. Perhaps you could grant only that person write access to the trunk and it is her job to make sure all merges into trunk are done correctly. Obviously you would want someone who's skillset is strong in development and concepts of source code management (specifically Subversion).

Answer 4

I would strongly discourage you from the proposed branching option. This is sometimes tricky for developers, so I let you imagine the mess you will end up with if all your designers start merging their branches on top of each other. And if the developers are working on the trunk, you may have to periodically do a merge TRUNK into some designers' branches.

One possibility could be to have one IIS for all your designers but each one (e.g. johndoe) would be working on his own application (let say http://johndoe.ueberserver.local/application) that is checked out onto a network drive (e.g. i:/johndoe/application). That way, John can work on some files and see the result in the browser.

When it is time for John to check in his changes, you can either let him do it or designate a "check in buddy" that will do it for him.

Answer 5

Hi

"the biggest problem is that the designers have to be careful not to step over each other and commit only their changes"

1. Can you provide them seperate workspaces on the same IIS server area? (with perhaps workspace areas checkedout under a folder named after them? ) This way they will only commit their work from their own workspaces. Of course this presumes they are working on non-overlapping code and hence wont overwrite each other's piece of work when they commit. Also they will need to be educated to do an svn udpate before they start their work so they have latest changes from others in their space to avoid any conflicts. ( i am always nervous when multiple people use the same workspace area)

2. You can have them make their changes but not necessarily have them run a commit. A single designated person can run svn commit once a day or more often - so as to avoid any unfortunate mistakes. I dont like this option too much - as I beleive it is quite easy for people to use multiple workspaces and follow simple tidy habits like committing with relevant messages etc (to help tracing/rollback) - a brief handholding session can easily cover the gaps in knowledge methinks.