Eclipse: collaborative dev on shared drive

238 views Asked by At

I am using Eclipse with the "statet plugin for R".
I am looking for a way to do collaborative development (like in google docs: allow people to modify code at the same time). Any preferred plugin for that? I have seen eXtreme Collaborative Development Environment but I don't know if it is good?

4

There are 4 answers

0
Konstantin Komissarchik On

There are plugins out there that will facilitate realtime code sharing. They commonly work by having all individual devs have their own copy of the files and synching changes back-n-forth on the fly. If conflicts are found you get to decide how to resolve them explicitly.

Here is one such plugin from ECF project:

http://wiki.eclipse.org/DocShare_Plugin

I would recommend a source control system for day-to-day development. Real-time code sharing works best for holding short-term collaborative editing or debugging sessions, doing code reviews, etc.

0
Spacedman On

I wouldn't use a shared drive, I'd set up a source code respository using Mercurial or Git and use that. I'm sure there's plugins for those for Eclipse.

2
David Heffernan On

How would you stop it being a free-for-all? In my experience, when developing code you want to control change, not have it forced upon you when you aren't ready for it.

Consider this scenario. You have a hard to explain defect in your code. You are steadily debugging it, throwing different data at it, looking at intermediate values etc. You are just about to trap it when BOOM, somebody else changes some other code and your results change because of that.

Spacedman is right, use a revision control system of your choice and keep in control of change.

If you want to do something like pair programming, but remotely, then use a remote screen, e.g. VNC, with Skype so that you can explain to the other what you are trying to achieve.

0
PaulHurleyuk On

I've used egit to add git functionality to Eclipse with StatEt and it works well. Allows others to edit code in whatever way works best for them (one repository, several individual repositories with frequent merges etc)