Multiple Developer Environment

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View

Hopefully this isn't too OT for this group.  If so, I'm sure one of
you will happily point me in the right direction. :)

I'm trying to set up a development environment for some incoming
programmers. My team is expanding from one (me) to four. Right now,
I'm working with a CVS repository that I've got checked out in a
private area on our development machine. I'm doing manual (command-
line) editing and cvs operations. Most of our incoming programmers are
not very comfortable on the command line, and I'm thinking that it
will be less time-consuming to set them up with GUI development
environments than to teach them all vi.

This is a PHP MySQL project, which involves some Perl and shell
scripting. Here's what I want:

   1. Developers will use a locally installed editor/IDE on their
desktop machines, but will be remotely writing to their home
directories on the development server.

   2. Developers will check out the project and be able to perform all
other CVS operations from within the context of the IDE, but on the
remote filesystem. For example, if they are on their windows
workstation and use the IDE to commit all their changes, I should be
able to go into their areas on the development server and run a 'cvs
diff --brief' and not see any results.

   3. We need to be able to force line terminators to '\n'

My initial experiments with Eclipse haven't been very successful. It
would seem that I can do the remote filesystem stuff okay, and the CVS
stuff okay (so long as I'm checking out the source to my local
machine), but I can't get the two plug-ins to integrate in any way. I
think my general idea is that instead of issuing direct cvs commands,
I'd be effectively saying things like "ssh user@machine cvs update,"

NetBeans seems to get close, but it still fails on points 2 and 3.
Again, I can only do local checkouts, and then use the "save a remote
copy" option to keep the actual development environments up to date.
Unfortunately, that means that commit's are also local and the remote
files still are left as "Locally modified." Also, NetBeans uses some
sort of (flawed, IMHO) intelligence to determine newlines and doesn't
offer a preference anywhere to dictate them. That's burned me on more
than one heredoc statement.

I'm absolutely willing to look at other IDEs as well. I prefer free/
open source if only because I can get off the ground faster. My
department could buy something, but it's a big company and purchase
orders take time.

Just wondering what other people have used in this type of
environment, or if anyone can help with a configuration for Eclipse or
NetBeans that will meet my needs.

Thanks for your time,

Re: Multiple Developer Environment

Quoted text here. Click to load it

Pandering to the inabilities of your development team is an approach
which will come back and bite you. I'd concede that learning vi can be
a big jump for some people - but IME developers are a lot more
productive when you remove all the distractions and eye candy
available in IDE programs. You could ease the transition by using a
CVS front end such as Chora.



Re: Multiple Developer Environment

El 27/04/2010 14:03, matt escribió/wrote:
Quoted text here. Click to load it

First of all, I would consider whether CVS working copies have a
reasonable performance in network locations. I've had many issues with
Subversion, which inherits the CVS concept of working copy information
scattered all around the directory tree. There're many lovely GUI tools
to handle version control but they'll all be painful to use if common
operations like "update" or "view log" take minutes to complete.

Secondly, while it can be interesting to have version control features
in your IDE, I don't think it's a must. There're nice IDEs and there're
nice GUI clients for CVS.

P.S. CVS and vi? Hey, you are a real macho man ;-)

-- - Álvaro G. Vicario - Burgos, Spain
-- Mi sitio sobre programación web:
-- Mi web de humor satinado:

Re: Multiple Developer Environment

On Apr 27, 10:31=A0am, "=C1lvaro G. Vicario"
Quoted text here. Click to load it

My experience playing around with NetBeans CVS integration is that
file-level operations (diff, commit, log, etc.) are pretty fast.  Even
with it's very attractive GUI diff view.  Site-wide updates (about 600
files in the repo) are a bit slower, but still not on the scale of
minutes.  Of course, that's in the context of a local CVS checkout.

Quoted text here. Click to load it

Hardly.  I'm just showing my age, low BS tolerance and aversion to
newfangled thingamagigs :)

I've talked it over with a couple of people in house, and I think the
best proposal so far is:

1. Setting up a Samba server on the development machine.
2. Mounting the development points on programmers' individual Windows
3. Doing the CVS operations on the mounted filesystem, as if it were
local.  (I think the only problem before is that the remote CVS
directories are not being updated, causing them to get out of sync,
even if the files themselves are in sync)
4. Using Eclipse as an editor with CVS integration and forgetting
about the whole Remote System Editor plugin.  I think the line
termination issue in NetBeans is a non-starter.  That's unfortunate,
since it's my personal preference between the two--nicer interface and
all the context-sensitive stuff comes up quicker.

I'm going to give that a whirl this afternoon and see how it goes.

Re: Multiple Developer Environment

El 27/04/2010 18:35, matt escribió/wrote:
Quoted text here. Click to load it

I'm not familiar with CVS. Can you write a hook that rejects commits
with non-conforming files?

-- - Álvaro G. Vicario - Burgos, Spain
-- Mi sitio sobre programación web:
-- Mi web de humor satinado:

Re: Multiple Developer Environment

On Apr 28, 3:10=A0am, "=C1lvaro G. Vicario"
Quoted text here. Click to load it

I'm not exactly sure what you mean by a "non-conforming file."  In
general though, I don't think that you can really write hooks for
anything, unless you modified the cvs binary's source directly.

Re: Multiple Developer Environment

El 28/04/2010 17:26, matt escribió/wrote:
Quoted text here. Click to load it

Then I said nothing. In Subversion, you can keep server-side scripts
that launch automatically when certain operations are performed (e.g., a
commit) and they are able to reject the current transaction. You could
use a hook to analize certain files and reject the commit if line
endings are not \n. Too bad CVS does not have such feature.

-- - Álvaro G. Vicario - Burgos, Spain
-- Mi sitio sobre programación web:
-- Mi web de humor satinado:

Re: Multiple Developer Environment [Getting OT...]

On Apr 28, 11:37=A0am, "=C1lvaro G. Vicario"
Quoted text here. Click to load it

I see.  From the CVS manual:

  [...] CVS by default converts line endings between the
  canonical form in which they are stored in the repository
  (linefeed only), and the form appropriate to the operating
  system in use on the client [...]

I.e., it's supposed to be intelligent enough to checkout/update files
to your CVS client with OS-appropriate line endings.  However, in
practice, I've got a bunch of files in my project that have "\r\n"
even after being checked out on a Solaris machine.  I honestly don't
think that functionality works as advertised, and it's probably easier
to choose an editor that will force the line endings than figuring out
how to make CVS do it.

At this point, the shortcomings of CVS fall just under the "worth it
to convert the whole repository to svn" bar.  Also, I'm used to CVS,
especially the independent versioning of individual files--don't know
how svn would affect our software release model/policies, and right
now I don't have the time to investigate it thoroughly.

Re: Multiple Developer Environment

Quoted text here. Click to load it

Well, I can report back moderate success.  The only problem I ran into
was that I set up the CVS checkout first before setting my general
preferences in Eclipse.  It would seem that if you don't explicitly
state UNIX-style line endings first, when you do the checkout, you end
up with Windows line endings in all of your CVS/* files.  That broke
cvs operations on the command line.  Other than that, this seems to be
the best-integrated solution, and I think we're going to stick with

Thanks again for everyone's time and comments.

Site Timeline