New features and bug fixes in SOS 4.0

[jclausius]

Vault is a totally different animal, and it would be unfair to make a comparison to SourceOffSite.

Vault is architected so your local clients have a distributed, cached copy of the tree located on your local disk. http://support.sourcegear.com/viewtopic.php?t=562. On startup/refresh, the Vault Client, asks what has been "changed" between my local copy and the servers copy of the tree.

In the extreme case, if someone added 300,000 files, and performed 200 branches, it may take a while to update the distributed cache of the tree.

However, for the most part, not much changes between the two copies say from when you shutdown at night until re-starting in the morning, thus VS.Net startups tend to be faster.

[Paul W]

Unfortunately, there wasn't much improvement made in SOS 4.0 with the speed of opening solutions in VS.NET. There's really no way to avoid downloading the file lists for all folders when you first load a solution.

Yes there is... Just don't use the integrated source control. Run SoS as a standalone client. That's how I do it, and it's fast and avoids all the in-your-face delays associated with the integrated source control.

[Paul W]

fortunately, we don't need Java anymore - just use C# which is more modern any does not make so many problems.

Heh heh heh... Now there's a real quote to look back on a few years from now.

[jcincotta]

We use and love SOS 3.5, but our biggest complaint is the speed (or lack thereof) of downloading file lists. It often times takes > 15 minutes when opening a large solution in VS.NET because SOS has to download all the file lists. Does SOS 4.0 address this problem?

Unfortunately, there wasn't much improvement made in SOS 4.0 with the speed of opening solutions in VS.NET. There's really no way to avoid downloading the file lists for all folders when you first load a solution.

With larger solutions we find this a huge problem. Sometimes > 1 hour to load VS.NET. Is there anything we can do? For example, we've tried doing a "get latest" from the SOS client first before loading VS.NET. This seems to speed up the load time, but sometimes results in problems if new files or projects have been added.

Another thing I've wondered about is if access time is in any way related to the size of the VSS database. In our case, multiple teams share a single VSS database. If we partitioned this into multiple databases, would this speed up access.

Overall, my sense is that our remote developers using SOS are spending half their day waiting on SOS/VSS. It's really, really slow. Yes, it's faster than remote VSS, but VSS being 12x as unacceptable doesn't make SOS adequate. It's a big problem for us and I'm quite disappointed with SOS 3.5. If there are things that could be done and/or techniques to troubleshoot/tune performance, a white paper describing them would be much appreciated.

Thanks,
Jay Cincotta

[corey]

With larger solutions we find this a huge problem. Sometimes > 1 hour to load VS.NET. Is there anything we can do? For example, we've tried doing a "get latest" from the SOS client first before loading VS.NET. This seems to speed up the load time, but sometimes results in problems if new files or projects have been added.

Another thing I've wondered about is if access time is in any way related to the size of the VSS database. In our case, multiple teams share a single VSS database. If we partitioned this into multiple databases, would this speed up access.

Overall, my sense is that our remote developers using SOS are spending half their day waiting on SOS/VSS. It's really, really slow. Yes, it's faster than remote VSS, but VSS being 12x as unacceptable doesn't make SOS adequate. It's a big problem for us and I'm quite disappointed with SOS 3.5. If there are things that could be done and/or techniques to troubleshoot/tune performance, a white paper describing them would be much appreciated.

Thanks,
Jay Cincotta

Hi Jay,

How many different SOS Servers are you running? If you have several teams using SOS, you may want to consider splitting the teams over multiple SOS Server machines.

We're currently looking at one particular change we may be able to make for 4.0.1 which would hopefully improve the performance of file list retrieval. Unfortunately, we can't improve the SourceSafe Automation component, but we do continue to look for ways to improve the SOS Server.

[paul]

>We're currently looking at one particular change we may be able to make for 4.0.1 which would hopefully improve the performance of file list retrieval.


You get my vote for improving file list retrieval performance.

Thanks,
Paul

[mark]

Very happy with 3.5.3 performance at cable modem speeds. I'm hoping that 4.0.x is not a performance degradation. We tried the collaberative version and seemed kind of slow at the time when it first came out. We quickly went back Source Off Site Classic 3.5.3. I don't want to go through that again.

[lbauer]

SOS 4.0 performance should be comparable to SOS 3.5.3, possibly faster in some operations, such as IDE integration.

SOS 4.0.1 was released earlier today:

http://support.sourcegear.com/viewtopic.php?t=947

Try the free demo download and see for yourself.

http://www.sourcegear.com/sos/downloads.asp

[Darby]

The 4.0 Client can be used with a 3.5 Server for basic operations, but some of the new 4.0 features will not work correctly until both are upgraded.

Can you elaborate on what new 4.0 features will not work? So far, using 4.0.2 Client with a 3.5 Server seems do *everything* I can think of (to use).

[lbauer]

Move isn't supported. Some Get by Label operations don't work. Any bugs caused by the SOS Server won't be fixed.

But as I said, most basic operations should work.