RE: Development Process
From: Eden Crane <ecrane_at_pacwest.com>
Date: 2005-04-05 22:22:17 CEST
We are in the same situation and have come to the conclusion you state; a paradigm change must to happen for people to move from VSS to SVN. You would think all you need to do is change the last 'S' to an 'N' and move the 'V' over position, but a lot of people feel its a much bigger change. Some of our challenges are that users check files out of VSS directly onto the web server (remote drive). This doesn't jive with subversion's practice of creating many files and lots of '.svn' directories. Our windows environment uses virus checkers that insist on scanning every file as you access it, and windows isn't very good at handling lots of small files. The update and commits take a loooooong time.
The conclusion we came to is that we have to check out the files directly onto web server (not via 'mapped drive'), meaning
I'm not sure how you guys do it today, but the Solution A and B are going to be quite different from how we work.
Lately I have been a fan of small changes. State the goals to the team directly 'In 6 months we want to be 100% on SVN', but make the changes gradual. Tell developers they can finish up their projects on VSS. Train them individually (win them over 1 at a time). Address their problems/questions in an individual manner, but stick by the decision to change and answer them with an honest 'no' when they ask for you to script broken VSS behavior back into SVN. Get their manager's support. A not-so-small change would be moving them to an entirely new IDE. I haven't used the Eclipse plugin for SVN, but I imagine its pretty good. If you can dazzle them with all the features a new IDE provides then the SVN process is incidental. If you can't change IDEs then take the time to learn about their IDE (or IDEs) and how SVN can be integrated with them.
If there are any SVN-related operations that can benefit from scripting then by all means write the script! The Windows mentality is to have an app that 'does it all'. In the *nix world, scripting is routine, so windows users often don't understand and say 'if this system is so much better why do you have to make a script to get it to work?' Remind them that this is a new system and there WILL BE things they have to learn and behavior that needs to change. Remind them they are intelligent people that should be capable of learning the new system and can adapt to those changes.
There will always need to be dialogue between programmers, there will always be problems with doing merges and commits that need to be resolved by calling programmer X and asking him/her what they did to the code. As you know, with Subversion they can work more independently (no more 'check out/check in' file). A useful thing Subversion can do is the global versioning, so we can know at least that 'Build 6237 is a good build' and check it out later/rollback if we run into problems on our production code. My biggest challenge is getting over the initial idea that changing our SCM (Source Control Manager) is somehow going to fix all of our issues. That is not the case; at the least we can put a system in that encourages good habits and flat-out denies some of the bad habits developers get into. Improving code testing and deployment process can also benefit a development group, SVN has hooks that make this easier but isn't necessarily the 'all-in-one' solution for code deployment.
I don't know if I answered your question on programming strategies, but I'd like to take this discussion out of the list and talk with you further. Since we both have a similar job to do, maybe we can help each other.
Is there a good reference guide or best practices guide for developing web based applications under subversion?
Thanks in advance
e - email@example.com
This is an archived mail posted to the Subversion Users mailing list.