I'm a one-man development team, and I still use CVS. The benefits are too nice not to even in my situation, and there is certainly plenty of proof that it can work well for teams of many different sizes.

"Best" is a word that starts religious wars :-) As long as everybody in the team is comfortable using the tools don't sweat it.

However I would advise that you get yourself using some sort of revision control system no matter how many people are developing (right down to just yourself) - CVS or Subversion are both good. Not having a way of rolling back changes will bite you one day - guarantee it.

In my experience it's people and methodologies that make the real difference to a successful development environment. Not tools.

A few years ago I used to work within a small group that had established a system that consisted of

• dev box
• ssh to dev box
• shared screen session
• every developer had a virtual screen within the same screen session
• with CVS

Maybe it wasn't the "BEST" development environment, but I enjoyed it a lot.

At the risk of sounding like an echo: I use CVS both for my private/personal projects as well as my professional ones. I have a PSERVER set up on my home box and for anything that I write here at work that isn't in a CVS respository on a company machine I create a repository for it on my home box and store it there.

Doing so buys me a couple of things:

1. I now have a backup of my work "offsite" since I don't trust the backups here
2. When I want to work from home I have the same code available to me at home as I do at work</li
3. Don't have to sneaker net my changes.

Enen the pages that make up my web site are under CVS control so I can track changes

I have recently convince my team mates here to start using CVS as well. It took some doing, but I did it.

Perhaps you could clarify what you mean by "the next step". Is there a possibility of more developers arriving on the scene? Or are you just (rightfully) paranoid about what could go wrong even with 2 people.

I was surprised when I didn't see CVS mentioned. Then I saw it in the last line. I'm rooting for CVS because of the sheer power involved. Being able to note differences between versions (ie: between multiple edits), as well as being able to restore previous versions should something go whacko. It's like having a mini-backup of the project at all times (though a proper backup is still required of course). Add the authentication schemes and the rest of the packaged goodies, and CVS just seems to glow.

Just curious: are some of these files interlinked with other files in the project? Do you need to be able to work on 4 separate files all at once without intervention from another developer who wants to make other changes to one of the files?

If the above content is missing any vital points or you feel that any of the information is misleading, incorrect or irrelevant, please feel free to downvote the post. At the same time, please reply to this node or /msg me to inform me as to what is wrong with the post, so that I may update the node to the best of my ability.

The best system that I've used was Perforce, but unfortunately that's not free. It is great because it allows you to map the physical file repository into different client structures depending on what you are doing - very powerful.

Michael

When you said "development environment," I was wondering if you meant software environment or human environment. From the text following, I guess you meant software environment.

Before you can tell what software environment best for you, you should figure out first what human environment, what development process, style, etc. you want for your "next step."

One of the best features of Perl for personal use is its flexibility. One of the main problems of Perl for team environment is also flexibility.

If you're planning to add more people, one thing you should figure out is what programming style, naming convention you want. It may seem inconsequential. But when you have a bunch of people writng code in completely different ways. That makes maintenance very hard.

One way to enforce style and convention is to put "templates" in source control. And everyone starts writing their codes from a template. (CVS and MS SourceSafe are both good stuff, but have opposite models. CVS has a client-view model; SourceSafe server-view. It's just a matter of preference which one more convenient to you. CVS is free, however.)

Deployment process is another important thing, especially if you build websites. Again, source control will be an important piece of tool there.

I found most programmers prefer simple editors to fancy and very very expensive integrated tools, such as those from Rational Rose (people who bought them or recommended them were often the people who didn't code).

Get yourself a graphing tool, such as Visio, if you prefer visualize your architecture graphically. At least, I found a graphical database schema extremely effective when used to communicate architecture among programmers.

You should define at each developmental stage, what "artifacts" should be produced. Like, during requirement analysis stage, artifacts could be Use Cases or requirements that have clear indications of "input-output." During design stage, they could be class diagrams, activity diagrams, database schemas. Etc, etc.

A purpose of those artifacts are to serve as some quality control checklist, so that least miscommunication may occur and minimal essential requirements may fall through the crack.

Whether your environment is "object-oriented" is not important at all; it's merely a marketing hype. To me, the best team environment is the disciplined one, yet still fosters creativity. But it would take a long essay or a book to describe how to do it.

But you should be aware that this is only part of the pie: version control is not the same thing as a development environment (read: configuration management).

From the 'version management with CVS':

CVSNT can do a lot of things for you, but it does not try to be everything for everyone.

CVS is not:

I'm sure you've noted most of the posts about CVS. Luckily, since you are using jEdit, you can install the "jEditCVS" plugin from the plugin manager, and you'll be up and running in about 15 seconds without ever having to reload the editor. Sometimes, jEdit is so cool it makes me want to scream. (Ok, so I did just scream, but don't tell anyone) (-:

Enjoy - JD

• Bugzilla - Probably the most well famous system for following up bugs. It is huge and has many options. But it is designed specifically for developers. It might be a little overhead for 2-men show, though.
• RT - Request Tracker is another system, which is less developer oriented, but is still an excellent piece of software. Very clean design and a lot of flexibility. Practically bug-free too. :)
• Mantis - good, but somewhat "green". It is still in heavy development, but has the potential.

My recommendation is RT. But you don't have to follow, since there are plenty of alternatives out there. Just grab the one you feel like will do the job and enjoy your development cycle.

Leonid Mamtchenkov aka TVSET

I've found that a Wiki serves as a great low-weight solution for this sort of thing if you trust your bug submitters/fixers.

I work on billing project with other 4 guys and we use CVS. It's very good free tool for different projects: small and big.

Also, try to look at subversion, because it will replace CVS. I've never tried to use this tool. I'm just planning to do it.

And there are two power utilities: diff and patch. But it's difficalt to use them for controlling of version in the big projects.

Update: Also, try to look at SourceForge Enterprise Edition. Many developers use it on SourceForge.

      
--------------------------------
SV* sv_bless(SV* sv, HV* stash);

On the communication front I have found Wikis and Blogs to be invaluable additions to the development environment.

For every project I have a wiki for common information (user stories, bug reports, etc.) and a blog that acts as a project diary for everybody.

Doing this has proved to be an excellent aid to communication within the development team, and with any external stakeholders. Also very lightweight and easy to setup and maintain.

With these at your service you're not that poor ;-)


• CVS Server for MS Windows
• Windows GUI Frontend to CVS Server
• Free Online CVS Book (a must read)
Open & free soure silently creeps into everywhere ;-)

Thank you: /me is now enriched! :)

Yep :)

<hits /me on head>Should have STFW before posting....<stop hitting>