Real-time simultaneous collaboration tool?

[Ethan Bauer]

Was wondering if there's a tool (maybe a plugin for Netbeans or Eclipse) that allows you to write code with others in real-time, of course it would have the full-functionality of any good IDE like Netbeans or Eclipse.
Something similar to what you can do with Google Docs: http://en.wikipedia.org/wiki/Google_Docs
Tell me what you use when you collab with other people on coding? Hope that there's something more effective than just dropboxing static files and having to re-upload when you've done your own part, looking for something that would allow multiple users to edit code at the same time.

[Tim Holloway]

You wouldn't want to do that with me. I move stuff around a LOT, and if there's any latency in the process (as there often would be), my natural twitchiness would result in stuff flying all over the screen at unpredictable moments.

If I was actually to attempt pair programming, I'd probably go with something like Adobe's Acrobat conferencing and designate one person to be the actual editor, do the discussions over the audio channel, and have people paste in code snippets for the editor person to insert/replace into the shared code display.

[Ethan Bauer]

Yeah, too bad there's no ideal tool for real-time paired programming right now.
We're thinking of using Subversion (http://en.wikipedia.org/wiki/Apache_Subversion) or GitHub (http://en.wikipedia.org/wiki/GitHub)
as a revision control system, I hope it'll do for our little project.
It'd be great if I could get some feedback/recommendations if anyone here has used Revision Control Software before. (http://en.wikipedia.org/wiki/Revision_control) (http://en.wikipedia.org/wiki/Comparison_of_revision_control_software)

[Tim Holloway]

Not sure what this would imply. Both SVN and CVS were designed for distributed development. GIT was designed for detachable distributed development. However, development in real time in another matter. If all the inserts, deletions, reformattings and massive code movements I do in a typical editing session were committed, I would end with revision numbers in the 10s of thousands. I'd stil go with a remote desktop approach myself and only commit when things were ready to go to the next level.

[Ethan Bauer]

Tim Holloway wrote:Both SVN and CVS were designed for distributed development. GIT was designed for detachable distributed development.

SVN = Subversion and GIT = GitHub, I'm guessing.. what's CVS?

So from what I gather, you don't really need real-time collab when working in projects, so I'm gonna drop that for now..
Our group for this project is rather small, only 4 programmers (including me) involved.
What I want to know though is how you document the changes, do you change small bits at a time and explain them when you meet up with the team? Or maybe you just break up classes/objects and assign each member to make his/her own part?
Are revision control software necessary? Tell me how you manage "distributed development" of software.

[Tim Holloway]

CVS is Subversion's predecessor. CVS had some problems, such as not allowing an empty directory to be placed under version control and poor support for move/rename file operations. Also a CVS commit could fail midway though, leaving the repository with an incomplete set of changes. SVN addressed those issues and replaced them with a new set of problems.

For the Linux project, neither one really addressed their needs, so Linus Torvalds influenced the development of "git", which is more distributed and better suited to having groups of independent teams on a very large project. Others have tried their own approach, such as Mercurial, which is favored by the Xen developers.

A good version control system is really a must on any large project, even if there's just one person. It provides a backup scheme, and it allows you to unwind your false starts and return to a baseline. Plus, if a project in production comes down with a serious error, but you've currently got the whole thing torn apart in the middle of creating a whole new release, you can pull the production build source and repair it and commit that as a maintenance branch while the main development continues. Or vice versa, where development team(s) work on branches and merge them into the main trunk when the changes are ready for prime time.

When you commit changes to a code repository, typically the version control system tags them with the ID of the committer and includes a user-supplied comment which hopefully includes what the change is. All the major VCS tools have the ability to display change logs and some form of difference display that highlights what the changes are. There are also good online tools for that. I use the Trac system (so does JavaRanch), and it has a very nice set of functions to not only browse and highlight versions and their changes, but to tie them back to their Trac task and trouble tickets.

Co-ordination will vary depending on the people and the needs. At the moment, I've got someone about to come onboard who has to change the text in a lot of web pages. And just this last week, someone else was introduced who'll be restyling the pages. They'll probably overlap on a lot of files, but at the moment, I'm leaning on giving each one of them a separate project branch to play with while I do the business logic mods in a third branch. Eventually, I'll merge all the different branches into the main trunk to create a new release.

[Joachim Rohde]

Never used it, but Netbeans has a collaboration plugin: http://netbeans.org/kb/articles/quickstart-collaboration.html

[Jeanne Boyarsky]

Didn't try it but saros exists for eclipse