wood burning stoves 2.0*
The moose likes IDEs, Version Control and other tools and the fly likes Multi-site source/version control? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Engineering » IDEs, Version Control and other tools
Bookmark "Multi-site source/version control?" Watch "Multi-site source/version control?" New topic
Author

Multi-site source/version control?

Bob Dobalina
Ranch Hand

Joined: May 24, 2001
Posts: 53
Hey all,

My company switched to ClearCase a few years ago, and while we've always hated it, we've learned to live with it. Well, with more of our development moving off-shore, our developers in India are having serious problems with performance, it taking ages to update views, check in code, etc. etc. On top of that, trying to explain ClearCase's... erm... personality to a non-native speaker is a bit challenging. So, we're looking at options.

The first is of course just going to multi-site ClearCase, which by the sounds will help performance, but also by the sounds requires some manual work by on-shore developers to merge in changes regularly that have been received from off-shore developers. Also, it doesn't help in the complexity issue.

That's not exactly ideal, but beyond that, since we universally hate ClearCase, this seems like a good time to look at other options. Can anyone give me some guidance about what other alternatives there are for some sort of version control system that is suitable for multi-site development and isn't as obnoxiously slow/complicated/painful as ClearCase? I've read a bit about Wandisco CVS, but don't know much about it.

Thanks,

-tim
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15959
    
  19

Most of the open-source VCS's are designed for use on projects with contributors all over the globe. CVS is, of course, the most common, though it has its warts. Subversion has pretty well taken over the Apache projects, and Mercurial is being used by the Xen team at Cambridge.

The key to all of the above is that people offshore don't send in updates any more than people in-house do. They simply check the updates in via whatever client program is suitable for the repository (which can include WebDAV clients for Subversion).

The only problem with this is if:

A) you don't trust the other guys (in which case, why do business with them?) - and don't forget, VCS's don't allow erasures, so the worst anyone can do is pollute the repository.

B) The remote site doesn't posess the basic infrastructure needed to check the changes in and out effectively.

C) The remote people don't/can't/won't posess the skill needed to use the same products that have worked well for thousands of other people around the world.

Cases B and C are pretty much surefire indicators that the one and only reason that offshore workers are involved is to be cheap and the project is ultimately doomed. Even case A is cause for concern. Otherwise there's no reason why internation collaboration should be a problem - at least as regards code management.


Customer surveys are for companies who didn't pay proper attention to begin with.
Bob Dobalina
Ranch Hand

Joined: May 24, 2001
Posts: 53
Thanks Tim. We have some concerns, but we're not taking about concerns with the off-shore labor, just concerns with the current means of getting code to them and their code back to us. Of course, all these projects are doomed, but for various other reasons.

Anyhow, anyone have experience with setting up or using these kinds of systems in a business environment?
Reid M. Pinchback
Ranch Hand

Joined: Jan 25, 2002
Posts: 775
Note that while ClearCase can be a bit of a pig, how you use it can make it 10 times worse. As I recall there were two kinds of views you could set up. Not sure I remember the buzzwords, but basically one behaved much like CVS - you had a local copy (called a snapshot?), and there were no real performance issues until you did a repository option (checkin, checkout, etc.). The other usage pattern (dynamic view?) was constantly performing repository operations on its own to propagate state changes and could be a real nightmare performancewise. You may already know all that, but just in case it is news, you might want to poke around and see if you have an easy option for getting out of your current predicament.


Reid - SCJP2 (April 2002)
Bob Dobalina
Ranch Hand

Joined: May 24, 2001
Posts: 53
Thanks, yeah, we're using snapshot views, but simple procedures like checking out files, performing merges, updating views, etc. still take absolute ages.
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Multi-site source/version control?
 
Similar Threads
The Hottest Jobs in Information Technology? Offshore Project Manager
user documentation
communication in Agile
Organizational changes for a growing team
JAVA/C++ Developer in Springfield, VA