RE: Development Process

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
A. Every developer has a webserver installed on their machine,
or B. The development server is accessed via Telnet/SSH/Terminal Services and the developers check out their code to C:\<DEVELOPERNAME> (and access the web page they are changing at http://<developername>.devserver.com).

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.

Thanks!

Eden
 
-----Original Message-----
From: jzorzi@marketlinksolutions.com [mailto:jzorzi@marketlinksolutions.com]
Sent: Tuesday, April 05, 2005 6:42 AM
To: users@subversion.tigris.org
Subject: Development Process

Is there a good reference guide or best practices guide for developing web based applications under subversion?
I'm trying to convince the developers in our organization to use subversion but they are resistant to the change in paradigm from VSS. They keep asking me to write scripts to make Subversion act more like VSS. I would like some programming strategies for web development to show them and prove to them that the switch to subversion requires a change in mind set.

Thanks in advance

Jay Zorzi
Systems Administrator, Information Technology

MarketLink Solutions
see further. achieve more.

e - jzorzi@marketlinksolutions.com
t - 416.260.2800 x299
f - 416.260.2893

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Apr 6 19:01:54 2005