I am sorry that I failed to make myself clear. I did not mean to lead anyone to believe that a version control tool can dictate a development environment. What I wanted to say is that the development environment should lead to a selection of version control tool appropriate to the environment. If the business process is one of an ad hoc development process, and the short and long terms goals are not in place, then a tool that does not enforces a controlled process is best to be selected. If the business process is one of an ad hoc development process, and the long term goal is to control the process more, then a tool that enforces a controlled process may be more appropriate. Of course feature creep and other development problems are not changed by the use of one version control system over the other. If the future goals are to get better control of project development, it may well be worth using a version control tool that helps control how changes are made rather than trying to get a development team to make process changes in the short term. It is especially hard to get process changes if the development team is reluctant to adopt process changes because they do not understand the long term goals and how the new processes move towards these goals. It can take some time to show the development team why they need to control a project, but the very livelihood of the business could be riding on these decisions in the short term so things may have to be changed today, and taught why tomorrow. David -----Original Message----- From: plug-discuss-admin@lists.plug.phoenix.az.us [mailto:plug-discuss-admin@lists.plug.phoenix.az.us]On Behalf Of Alan Dayley Sent: Monday, February 23, 2004 11:02 PM To: plug-discuss@lists.plug.phoenix.az.us Subject: Re: CVS opinions On Monday 23 February 2004 10:37 pm, David Demland wrote: --[clip]-- > Version control allows for a development centered approach. This works when > the business processes are young and immature. In this environment the > focus is on “just getting the code out” not necessarily “what is the system > doing and in what time frame will it be completed”. It is not unusual in > this environment for code to be produced quickly, but projects seem to > always be out of control. A good example of this is everyone making > whatever changes they want when they want. > > In a system centered approach, the over all system is looked at and change > is more controlled. In this environment code output is lower, but the > projects are under more control. A business that has this type of control > tends to be a more mature business, form a process stand point, and thus > projects are delivered closer to projected timelines, closer to defined > requirements, and most often with less feature creep. In this environment > change comes only after some sort of analysis. --[clip]-- You make some excellent points, David. I have to disagree a bit on the quoted part above. What you describe is two different development environments, neither of which is dictated by the version control tool. CVS or VSS can be used in either the "out of control" or the "system centered" environments. I would assert that if development is out of control, the process needs changing, not the versioning tool. For example: Suppose it is found that merge conflicts happen a lot and multiple programmers are frequently working on the same code file or even function. I would say the process of who works on what code and the architecture of the code needs to be changed. This has little to do with file locking or merge capabilities of the tool. The development is not structured well. Other problems like feature creep and "just getting the code out" are certainly neither controlled nor accellerated by the version control tool. I guess I am just saying that one should not expect that picking a different or "the right" version tool will not, of themselves, solve development process problems. Alan --------------------------------------------------- PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us To subscribe, unsubscribe, or to change you mail settings: http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss --------------------------------------------------- PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us To subscribe, unsubscribe, or to change you mail settings: http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss