Geeks With Blogs
Patrice Calve Life's short, have fun

I'm on a new assignment and working remotely.

It has been a while since I had to work remotely, as usually I'm relatively “close” to the source code (VSS) database.

So, I started to work remotely by using Remote Desktop to access a dev box at the client site until I have my localhost setup with the necessary software and remote access (VPN).

Things go smoothly (speed-wise), but the remote dev box is share with others.  So, Remote Desktop connections are limited and running/debugging/testing is very problematic. 

I installed the necessary software on my desktop.  Ran Visual Studio 2003 and got the project from VSS (network share over VPN).....    2.5 hours to get 44 folders and 825 files (7.43 Megs).  The network bandwith is really good. 

This is mind numbing slow and impractical.  After that was done, I tried closing VS and re-opening the ASP.Net project: 1.25 hours.  ouch...

It's weird....  2.5 hours to get 7.43 megs of files, but I can remote destkops to 5 different remote desktops and the speed is very good !

I read about the Web Service functionality of VSS 2005 and the Proxy feature of Team Foundation Server.

I could be wrong, but neither seem to be a very “efficient“/super-fast remote solution.  VSS 2005 requires a network share and TFS is used only to locally cache a certain number of files.

For VSS2005 Web Service, I was expecting something that didn't require a Network Share.  A Web Service only.  With all of the guts to make remote work efficient.

For TFS, I was expecting a “replication“ type of service between the primary and the secondary.  The network goes down? No problem: Replication will kick in when it comes back.  The network is slow between the two? no problem: the dev's machine <-> server is fast.  There's a merge conflict after a Replication re-synch? no problem, there are merge conflict agents assigned to the task.

For the “Service“ side of the functionality, I'd like to see a “Get Latest Version“ based on the last time the GLV was done + Bundle all of the files in one compressed file and stream it to the client requesting it.

Since VSS already uses Delta's, why not send the changes when it makes sence: On 10 Megs of text files, if only 1kb has changed, why not send this 1kb?  Simply use the algorithms as those found in Backup Software.

We'll have to find faster approaches... new Source Control solutions, for example.  But for now, it's way faster to use Remote Desktop! 

Heck, I could ask for a Desktop Computer (just for me) on the client site , install the software there and Remote Desktop to that box !

Pat

Posted on Friday, June 30, 2006 8:52 AM | Back to top


Comments on this post: Why is a Remote Desktop faster than developing locally?

# re: Why is a Remote Desktop faster than developing locally?
Requesting Gravatar...
2.5 hours for a 7.5mb check out seems very slow. I work with large solutions over VPN & VSS regularly and things check out nearly as fast as on a local connection. If you have AV running, try turning off "real-time" protection when you're getting files (I use Norton AV and it really slows things down). Otherwise I suspect you have some type of networking issue.

Good luck.
Left by carl on Jun 30, 2006 9:58 AM

# re: Why is a Remote Desktop faster than developing locally?
Requesting Gravatar...
Wow..

What a difference. I tried with and without Norton AV's Auto-Protect:
- With: 01:11:23
- Without: 00:00:57

A minute vs An hour. I would have understood 10% slower with AV, but not ridiculously slower.

Thanks very much
Left by Pat on Jun 30, 2006 12:33 PM

Your comment:
 (will show your gravatar)


Copyright © Patrice CalvĂ© | Powered by: GeeksWithBlogs.net