Subversion and distributed development

Whether we like it or not offshoring is here to stay. So its common to have teams spread across the world i guess. Is subversion well equipped to handle such situations?
I'm not able to phrase my question properly i guess since i too am not sure if such issues can exist

. But what am trying to say is, can a team in country X add files to subversion repository located locally (so that the changes can be updated to the repository real quick) while a team in country Y adds to their local repository and somehow everything gets merged properly even though the changes reside in different repositories/file systems.

I think that both teams would use the same repository, whether it's located in one place or another. Subversion works well in a distributed environment, since the least amount of data possible for a given operation is passed between client and server.

For example, I work in Michigan, and the rest of my team is in Illinois and Florida. I just scripted our database, which is composed of 468 objects (tables, views, stored procedures, etc.), to my local hard drive, writing one file per object. It took me far longer to script it (~ 20 - 30 minutes) than to commit all 468 script files to our Subversion repository (~ 20 - 30 seconds). Both the database and the Subversion repository are located in Illinois.

Craig
[ January 21, 2005: Message edited by: Craig Demyanovich ]

I don't think that's how it works. Do you know of any version control system that works that way?

All distributed teams I've heard of simply use a central code repository. With todays internet capacity, that shouldn't be much of a problem, anyway.

I dont know much.
My brother works for a company that uses rational clear case i think. He was telling me that they do distributed development out of india and US.
He was mentioning about repository getting replicated between US and India and that it takes a while before somebody adds something to the repository say in US and the same being visible to people working out of India and vice versa.
He also specifically mentioned if that there were considerable delays in adding related files from one location, things wouldn't replicate uniformly to the other location and a build,if run on the other location at that time, would fail momentarily until replication goes through completely.
I dont know the specific details, may be i shall ask him later.

Most people that use clearcase use dynamic views, so you are always looking at the lastest version of the repo. Subversion (and CVS) use the copy-modify-merge model, so you are using a working copy and commit and update (sync your copy with the repo) only when you want. Since only the diff's get transfered with a commit and update, bandwidth shouldn't be an issue. Yuo can also setup Subversion to compress data before sending over the wire if it is an issue

Originally posted by Jeff Machols:
Most people that use clearcase use dynamic views

Really? In my experience, maybe 1 in 5 developers I've seen have used dynamic views, although that might be due to the particular ClearCase servers getting too much traffic (e.g. one shared repository for a whole company of thousands of users).

Ilja I remember I have read about a cluster version control system but I cannot remember its name. I will try some googling and come back.

--
./pope
[the_mindstorm]