You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Suu Quan <sq...@portal.com> on 2005/07/16 19:38:57 UTC
Working across the continents
Newbie here.
Background: our shop is Clearcase/UCM, and it's not working optimally
for us -> investigating alternatives. One question:
Situation: Our development teams (300 developers) are split 30% USA, 70%
India, over a not too fast network. I wouldn't call it slow, but it's
not super fast. (I've worked at 50% USA, 30% Singapore, 20% Gemany
situation, thus they were working 24 hours a day). So, my situation is
not unique.
If we have a single repository, say in the USA, then developers in other
continents will have to deal with our -not too fast, but decent-
network. Of course, one solution is to upgrade the networ$$$k.
If we have distributed repositories, then developers access a local
network (faster) and can also take advantage of the work done by other
teams.
I've gone thru the svn book and there is no talk about this topic.
Question is: what is SVN solution for teams working over long distance?
Thanks in advance
Suu Quan
Release Engineering
Re: Working across the continents
Posted by Yashpal Nagar <ya...@linux-delhi.org>.
You are in same boat in which i was 3 months back.:)
I would recommend you to try svnreplicate which is amazing.
Read svk FAQs before trying it.
I have setup of few megs of repository one in US and other in india.
Its amazed, the syncing is smooth and you can have n slave servers.
read more at https://open.datacore.ch
Really good work!
Regards,
Yash
On Sunday 17 Jul 2005 1:08 am, Suu Quan wrote:
> Newbie here.
>
>
>
> Background: our shop is Clearcase/UCM, and it's not working optimally
> for us -> investigating alternatives. One question:
>
>
>
> Situation: Our development teams (300 developers) are split 30% USA, 70%
> India, over a not too fast network. I wouldn't call it slow, but it's
> not super fast. (I've worked at 50% USA, 30% Singapore, 20% Gemany
> situation, thus they were working 24 hours a day). So, my situation is
> not unique.
>
>
>
> If we have a single repository, say in the USA, then developers in other
> continents will have to deal with our -not too fast, but decent-
> network. Of course, one solution is to upgrade the networ$$$k.
>
>
>
> If we have distributed repositories, then developers access a local
> network (faster) and can also take advantage of the work done by other
> teams.
>
>
>
> I've gone thru the svn book and there is no talk about this topic.
>
>
>
> Question is: what is SVN solution for teams working over long distance?
>
>
>
> Thanks in advance
>
>
>
> Suu Quan
>
> Release Engineering
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Working across the continents
Posted by Kyle Kline <ky...@gmail.com>.
I have had good luck with SVN used in *very* geographically dispersed
locations over not-so-fast but decent connections to the centralized server.
Plus, the nature of SVN being able to do hot backups with both the BDB and
FSFS options means 24x7 availability. I wouldn't hesitate to recommend it
... you can go with SVK (which is an awesome tool btw), but given how well
SVN performs over a WAN by itself, I'm not sure the extra complexity would
be warranted (in some cases.) Mileage may vary.
On 7/16/05, Ben Collins-Sussman <su...@collab.net> wrote:
>
> Suu Quan wrote:
>
> > Question is: what is SVN solution for teams working over long distance?
>
> Answer: SVN is designed for WAN. That is, it assumes network is a
> scarce resource and thus is optimized to use it as little as possible.
> It sends only file "diffs" in both directions over the network, and many
> commands are optimized to not use the network at all.
>
> Still, SVN has no database replication. It is a centralized system. If
> you're looking for a "distributed" system, try SVK
> (http://svk.elixus.org), which is a separate product that builds on top
> of Subversion's libraries.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
Re: Working across the continents
Posted by Ben Collins-Sussman <su...@collab.net>.
Suu Quan wrote:
> Question is: what is SVN solution for teams working over long distance?
Answer: SVN is designed for WAN. That is, it assumes network is a
scarce resource and thus is optimized to use it as little as possible.
It sends only file "diffs" in both directions over the network, and many
commands are optimized to not use the network at all.
Still, SVN has no database replication. It is a centralized system. If
you're looking for a "distributed" system, try SVK
(http://svk.elixus.org), which is a separate product that builds on top
of Subversion's libraries.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Working across the continents
Posted by Chia-liang Kao <cl...@clkao.org>.
Ravi Giri <ravi.giri <at> gmail.com> writes:
> destination (like clearcase merge hyperlinks). So, it should be
> possible (but probably non-trivial) to develop a graphical version
> tree browser as well
FYI, on the svk-dev list there are people talking about branch / merge
visualisation.
Cheers,
CLK
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Working across the continents
Posted by Ravi Giri <ra...@gmail.com>.
On 7/18/05, David Weintraub <qa...@gmail.com> wrote:
We have 400+ developer's across 4 sites, but we use SVK as well.
> etc. Subversion is still missing some rather important features. Its
> hooks are not as rich as ClearCase's triggers, and you don't have the
True, but it has all the most commonly used/required ones - pre/post
commit, etc.
> UCM model like you do in ClearCase.
UCM is just a way of enforcing a particular development process model,
which doesn't necessarily match your process model. There are other
ways of acheiving this (whether in clearcase or SubVersion) without
the limitations and overhead that UCM brings with it.
> In fact, because of missing features in Subversion's merging
> capabilities, it cannot handle the
> develop-on-branch-and-merge-to-integration model that ClearCase
> handles so well.
Agreed. Un-availability of merge tracking is a big pain. but see below ...
> Subversion has much better network security than ClearCase since you
> can easily use Apache with https or svn+ssh. The best you can do with
Yes. Also better ACL's (when used with Apache).
> There is even a package called SVK that allows you to have local
> copies of your repository which is very similar to MultiSite. You use
> SVK to check in and out of your local repository, then later sync the
> local repository with the other copies you might have around the
> world.
SVK also has *very* good merge tracking. We started deploying SVK just
as much for this feature as for the repository-sync capability it has.
The major fear now is that when SubVersion eventually incorporates
merge-tracking, it will probably be in-compatible with the
merge-tracking the SVK does, so we'll be in trouble.
SVK merge-tracking is quite similar to clearcase as well. It attaches
'properties' (just like clearcase attributes) to the merge source and
destination (like clearcase merge hyperlinks). So, it should be
possible (but probably non-trivial) to develop a graphical version
tree browser as well :-)
--
Ravi
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Working across the continents
Posted by David Weintraub <qa...@gmail.com>.
Suu:
There's a big, big difference between ClearCase and Subversion.ClearCase is a much more mature tool with tools to handle extremelylarge developer sites (like 300 developers). With MultiSite, ClearCasehandles your situation with ease. Of course, ClearCase costs a ton ofmoney (especially for 300 licenses), is a bear to manage, is slow, andneeds constant baby sitting.
I can't imagine a single Subversion repository handling 300 veryactive developers -- plus testers, documenters, requirement managers,etc. Subversion is still missing some rather important features. Itshooks are not as rich as ClearCase's triggers, and you don't have theUCM model like you do in ClearCase.
In fact, because of missing features in Subversion's mergingcapabilities, it cannot handle thedevelop-on-branch-and-merge-to-integration model that ClearCasehandles so well.
However, Subversion can be helpful in your environment if your 300developers are working on 25 or so separate projects, and you don'tneed the develop-on-branch-and-merge-to-integration model that UCMimplements.
The great thing about Subversion is the fact that you no longer haveto be concerned with the client side of things. Users can use whateverSubversion client they prefer. You don't have to worry about triggerscripts, licenses, or whether a user has the right equipment. Forexample, Subverion's hooks are handled on the server end which meansthat you only have to worry about hooks running on a single machine.ClearCase's triggers by contrast run on the client which means youhave to make sure your trigger scripts run on every single one ofthose 300+ clients.
Subversion has much better network security than ClearCase since youcan easily use Apache with https or svn+ssh. The best you can do withClearCase is establish a VPN or use the awful web interface.
Subversion is also network light when compared to ClearCase. EvenClearCase's "snapshot views" need server connectivity to function. Ifyou're not connected to the server, you have to "hijack" files inorder to edit them, then hope that ClearCase can figure out what isgoing on. The last time I used ClearCase with hijacked files, itsdefault mode was to overwrite the hijacked files and not check themout with the changes you made.
Many times, ClearCase also forgot to check the basis of my hijackedfiles. For example, I had version /main/5 checked out and I hijackedit. Someone checked in version /main/6. When I update my view,ClearCase detects that my file based upon version /main/5 washijacked, and gives me a choice of 1). ignoring the hijack, 2).checking out the file with my changes, or the default 3). overwritingthe file with what is on the server.
If I chose the second option, ClearCase would checkout the file in myview, and keep my changes. Unfortunately, my changes were based uponversion /main/5 and the latest copy is at version /main/6. If I checkin my copy, I would lose the changes in version /main/6. Not a greatidea. I hope that IBM has fixed this issue.
Subversion, on the other hand, allows you to make changes withoutconnecting to your server. (Not too sure how locks are now handled...)You only have to connect to the server on commits, checkouts (whichyou only do the first time you make a working directory), and updates.
There is even a package called SVK that allows you to have localcopies of your repository which is very similar to MultiSite. You useSVK to check in and out of your local repository, then later sync thelocal repository with the other copies you might have around theworld.
Whether Subversion is right for you depends upon a lot of factors. How"technical" are your developers? Can they handle straight /main branchdevelopment? Can they manage using a version control system without afancy front end that abstracts the development cycle? (Of course,Subversion is much easier to use than base ClearCase, so there may notbe a need for the big abstraction layer). Also are you talking aboutone really, really big project, or lots of little projects?
On 7/16/05, Suu Quan <sq...@portal.com> wrote:> > > > Newbie here. > > > > Background: our shop is Clearcase/UCM, and it's not working optimally for us> -> investigating alternatives. One question: > > > > Situation: Our development teams (300 developers) are split 30% USA, 70%> India, over a not too fast network. I wouldn't call it slow, but it's not> super fast. (I've worked at 50% USA, 30% Singapore, 20% Gemany situation,> thus they were working 24 hours a day). So, my situation is not unique. > > > > If we have a single repository, say in the USA, then developers in other> continents will have to deal with our –not too fast, but decent- network. Of> course, one solution is to upgrade the networ$$$k. > > > > If we have distributed repositories, then developers access a local network> (faster) and can also take advantage of the work done by other teams. > > > > I've gone thru the svn book and there is no talk about this topic. > > > > Question is: what is SVN solution for teams working over long distance? > > > > Thanks in advance > > > > Suu Quan > > Release Engineering > >
-- --David Weintraubqazwart@gmail.com
Re: Working across the continents
Posted by Adrian Hoe <ma...@adrianhoe.com>.
On Jul 17, 2005, at 3:38 AM, Suu Quan wrote:
> Newbie here.
>
>
>
> Background: our shop is Clearcase/UCM, and it’s not working
> optimally for us -> investigating alternatives. One question:
>
>
>
> Situation: Our development teams (300 developers) are split 30%
> USA, 70% India, over a not too fast network. I wouldn’t call it
> slow, but it’s not super fast. (I’ve worked at 50% USA, 30%
> Singapore, 20% Gemany situation, thus they were working 24 hours a
> day). So, my situation is not unique.
>
>
>
> If we have a single repository, say in the USA, then developers in
> other continents will have to deal with our –not too fast, but
> decent- network. Of course, one solution is to upgrade the networ$$$k.
>
>
>
> If we have distributed repositories, then developers access a local
> network (faster) and can also take advantage of the work done by
> other teams.
>
>
>
> I’ve gone thru the svn book and there is no talk about this topic.
>
>
>
> Question is: what is SVN solution for teams working over long
> distance?
My company just switch to SVN (from CVS) recently. The switch is
still not completed and we are still in trial run. I think my
management will decide on SVN soon.
Our server is on DSL, 512K download, 256K upload, dynamic IP. We now
have 16 repositories out of 67 on SVN and our development teams
spread in Malaysia, China, Austria and Russia. Sometimes in Taiwan
and Hong Kong as well. 800+ revisions daily. The largest repository
is 12GB of source including revisions.
We have no problem with speed. Sometimes, we can have a quick coffee
and do some stretching during SVN access. :)
We are happy.
Best regards,
--
"If you missed the rising sun and the morning dew, don't miss the
beautiful sunset." -- Adrian Hoe inspired by Michal Nowak, June 15 2004
http://adrianhoe.com