> -----Original Message----- > From: Marc Brooks [mailto:[EMAIL PROTECTED] > Sent: Wednesday, February 08, 2006 1:27 PM > Subject: Re: Source Control - What do you use, and why? > > Also not that there is an MSSCCI provider to > plug into DevStudio, VS2003, VB6 and other older VSS compatible > clients, so you can actually do IDE-integrated source control of any > of those products as well (with the attendant limiations that the > MSSCCI interface has).
I believe you meant "Also *note* that there *is* an MSSCCI provider ..." :-) > > > Without using the cache servers, how is the performance over a VPN > > or other WAN link? > > If your files are reasonably sized, and your projects not huge, it's > fine... think web-service-based document management system. It's not > far from the performance of SharePoint documents (at worst). We have a small team in Beijing using a TFS server in Colorado and the performance has been good enough that we haven't bothered to install the TFS Caching Proxy. We have also used ClearCase and this is an area where ClearCase kind of bites. It was designed as a LAN protocol and is way too chatty to work well over VPN much less a WAN. Their work-around is called "multi-site" but that requires the creation of branches at each site and then those branches have to be merged with each other frequently. It's kind of a pain unless you can afford CC admins. BTW there is a new-ish ClearCase Remote Client that improves performance when using a CC server over the WAN. It can be a reasonable alternative to multi-site. Overall, our experience with TFS has been wonderful too. I really like the SVN style of operation: edit/[merge]/commit. Being used to ClearCase's version-space branching, I'm still getting used to TFS's path-space branching but I don't foresee any problems with this approach. Shelvesets are quite handy allowing you to quickly put aside a bunch of changed files fix a bug in one of those files, check in that one bug fix and then restore back (unshelve) to what you were doing before. I also really like the changeset notion where a set of related file changes can be checked in together and atomically. And if you use the work item tracking (defects, issues, tasks, requirements, etc) you are encouraged to assign each changeset you checkin an associated work item. This makes it real easy to see what files were touched as part of a defect fix. Plus the performance (local and remote) is really good and your whole code base is stored in SQL Server 2005 which runs mission critical apps in many companies. -- Keith Hill =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
