We're running SourceSafe on an internal server at my company but have
been asked to look into running the server component on a webserver
outside of our corporate network. We would use either Visual Studio or
the SourceSafe client application to check files in/out.

+ Does SourceSafe allow the hosting of the  server component somewhere
other than the local network? (when I choose 'Add SS Database' the
verbiage implies that the ini file I'm looking for is on the local
network.)

+ Would the source code be available only to people whom we've set up
as users or does hosting it outside of our firewall basically publish
our source code?

Alan Constantine's home page describes how to set this up:
http://alinconstantin.homeip.net/webdocs/scc/VSS_Internet.htm

But note there are some REALLY IMPORTANT items missing from his
instructions (unless he's updated it recently).  To save you a BUNCH
of grief, here they are:

- Each client user must have a Windows user account on the server (or
an account in AD if your server is using AD).
- Each client must *also* have a VSS account set up on the server.
- The VSS user account must be named EXACTLY like the Windows account
name for the user.
- The VSS user account PASSWORD must be EXACTLY like the Windows
account password.
- When you create the Windows user account(s), make sure you set them
so the passwords don't expire and so that the user is not required to
change it on first log in.
- You must give each VSS user full read/write permissions on the
folder that contains the VSS database.
- You need an SSL certificate on the server for secure
communications.  It will NOT work over HTTPS without a valid SSL
certificate!!!!
- You must access the VSS services via an HTTPS URL (secured URL).  I
would NOT do this without a secure connection!!! (not even sure if you
CAN).
- When accessing VSS server from VSS client over HTTP, you will have
frequent write failures.  Use the VSS client only for simple stuff
like browsing projects, comparing versions, and labelling.  Do NOT use
it for transferring large quantities of files in or out of the
server.  It's EXTREMELY unreliable over HTTP(s).
- If you use the VSS client, you must set up a "net use" to the
path... something like:  net use \\mydomain\myvssfolder /
user:myvssusername *
   - Yes, you can do this with the VSS share over HTTP.  Setting up
your server creates a web folder, which you can "net use" across the
internet... You can even browse if via Windows Explorer and any
Windows application... It's just like connecting to a network share.
- To access the VSS server over HTTPS from Visual Studio, you do NOT
need to connect to a network share.  File transfers between Visual
Studio and VSS over HTTP seem to be totally reliable, unlike transfers
between the VSS client and the server over HTTP(s).
- When setting up your connection from within Visual Studio, it's
confusing... REALLY confusing.  After you point to the server via
something like \\mydomain, then the path is \\localhost\myvssfolder.
Seems odd, but you do have to reference the server as if you're
locally on it.
- You will frequently get $8000005 errors because for some reason, the
HTTPS service on the server isn't responding for VSS requests.  You'll
have to remote control the server and bounce (restart) the HTTPS
service.  If you're running web sites on that same server, this will
reset those web sites and lose any open sessions.
- You may time out when going to the pending checkins tab in Visual
Studio if you have a medium or larger solution.  This may also happen
if you're checking in a bunch of files.  VSS over HTTP(s) is way way
slower than over a LAN with a UNC connection.
- Lastly (or firstly), you need to tell Visual Studio to use VSS over
HTTP (tools, options, source control, change the drop down to
"Microsoft Visual SourceSafe (Internet)".

Hope this helps and GOOD LUCK!  You're going to need it!  You'll find
that there's virtually ZERO help out there for this type of set up.
Apparently, very few people are doing it, and I'm betting it's because
it's so difficult to find informatoin on setting it up properly.
Sometimes I think that I and Alan are the only 2 people on the planet
using this feature... and I'm not so sure he's actually using it this
way.

--------------------------
Owner/Operator of
www.MichaelsAttic.com

On Feb 11, 3:37 pm, engwar  wrote:
> We're running SourceSafe on an internal server at my company but have
> been asked to look into running the server component on a webserver
> outside of our corporate network. We would use either Visual Studio or
> the SourceSafe client application to check files in/out.
>
>  Does SourceSafe allow the hosting of the  server component somewhere
> other than the local network? (when I choose 'Add SS Database' the
> verbiage implies that the ini file I'm looking for is on the local
> network.)
>
>  Would the source code be available only to people whom we've set up
> as users or does hosting it outside of our firewall basically publish
> our source code?

engwar:

As you may have seen from Mike's post, there is a lot to setup to allow 
Remote Access to SourceSafe.  And even then you can only use a Visual 
Studio plugin to get to the VSS database.

Another alternative you may want to investigate is SourceOffSite.  The 
setup is a tad bit easier, and you can use either a SourceOffSite 
Explorer or Visual Studio to access your VSS databases.

There is a free 30-day trial for the tool at http://www.sourcegear.com/sos

HTH
Jeff Clausius
SourceGear

engwar wrote:
> We're running SourceSafe on an internal server at my company but have
> been asked to look into running the server component on a webserver
> outside of our corporate network. We would use either Visual Studio or
> the SourceSafe client application to check files in/out.
> 
> + Does SourceSafe allow the hosting of the  server component somewhere
> other than the local network? (when I choose 'Add SS Database' the
> verbiage implies that the ini file I'm looking for is on the local
> network.)
> 
> + Would the source code be available only to people whom we've set up
> as users or does hosting it outside of our firewall basically publish
> our source code?
>

Be careful with SourceOffSite.  Check their bug fix history and make
sure they've fixed the following bug:

I used it around 2002~2003 and I confirmed the following:  My settings
were set to NOT delete my local data during check in.  I checked in my
code while I had Windows Explorer open to my source folder.  I saw my
files disappear one by one as they were checked in.  Then I looked
into the server and it failed to check them in.  So, I had nothing
checked in and it deleted my local copy.  VERY Dangerous!

I do realize that a lot of people have had success with this product,
but I and my company stopped using it immediately after I was able to
reproduce that fatal flaw (it was difficult to reproduce as it didn't
do that every time).  If it weren't for that, I'd highly recommend
that product.  Aside from deleting any chance of recovery of my source
code, everything else about it was great, if you could afford the $350/
seat license fees.  It was fast across our LAN and WAN and it worked
across the internet (I think).  VSS HTTP is extremely tricky to set up
and is very very slow, but highly reliable and you don't have to spend
money on a 3rd party product.

Good luck with whichever product you choose to go with.

--------------------------
Owner/Operator of
www.MichaelsAttic.com

On Feb 12, 4:14 pm, Jeff Clausius  wrote:
> engwar:
>
> As you may have seen from Mike's post, there is a lot to setup to allow
> Remote Access to SourceSafe.  And even then you can only use a Visual
> Studio plugin to get to the VSS database.
>
> Another alternative you may want to investigate is SourceOffSite.  The
> setup is a tad bit easier, and you can use either a SourceOffSite
> Explorer or Visual Studio to access your VSS databases.
>
> There is a free 30-day trial for the tool athttp://www.sourcegear.com/sos
>
> HTH
> Jeff Clausius
> SourceGear
>
>
>
> engwar wrote:
> > We're running SourceSafe on an internal server at my company but have
> > been asked to look into running the server component on a webserver
> > outside of our corporate network. We would use either Visual Studio or
> > the SourceSafe client application to check files in/out.
>
> >  Does SourceSafe allow the hosting of the  server component somewhere> > other than the local network? (when I choose 'Add SS Database' the
> > verbiage implies that the ini file I'm looking for is on the local
> > network.)
>
> >  Would the source code be available only to people whom we've set up
> > as users or does hosting it outside of our firewall basically publish
> > our source code?- Hide quoted text -
>
> - Show quoted text -

Oh!  I forgot to respond to the following:

> And even then you can only use a Visual
> Studio plugin to get to the VSS database.

You can do a net use to the web share like this:

net use \\mydomain.com\myVssFolder

Or, if you like to use the old fashioned drive letters on your shares,
you can assign a drive letter to it too.  Then, you can access it just
like you access a VSS database on your LAN... just crank up VSS
client, add a database, browse to \\mydomain.com\myVssFolder (or the
drive letter you assigned to the share), double click that INI file
and you're good to go.  Just don't use the client to check in large
chunks of files.  Feel free to use it to label, browse, and get files
though.  Uploading is just not all that reliable with the client...
it's actually a flaw with MS's web-shared folders technology because
web shares from SharePoint have the same problem.  VSS access from
within Visual Studio seems to be rock solid though (after you get
passed the hair pulling configuration, that is!)

Good Luck!  And as Jeff said, try to go with SourceOffSite if they've
fixed that particularly dangerous bug.

One other recommendation:  SourceVault.  It's a totally different
source code control product and much more powerful than VSS and works
across the internet right out of the box... even has events so you can
be notified the moment someone checks something in.  The UI in their
client looks an aweful lot like VSS, so if you're already familiar
with VSS, you'll feel right at home.  Unlike VSS, it has a seperate
server component and is a true client-server product, where VSS is a
client only product that stores it's stuff on a network share.

--------------------------
Owner/Operator of
www.MichaelsAttic.com

On Feb 12, 4:14 pm, Jeff Clausius  wrote:
> engwar:
>
> As you may have seen from Mike's post, there is a lot to setup to allow
> Remote Access to SourceSafe.  And even then you can only use a Visual
> Studio plugin to get to the VSS database.
>
> Another alternative you may want to investigate is SourceOffSite.  The
> setup is a tad bit easier, and you can use either a SourceOffSite
> Explorer or Visual Studio to access your VSS databases.
>
> There is a free 30-day trial for the tool athttp://www.sourcegear.com/sos
>
> HTH
> Jeff Clausius
> SourceGear
>
>
>
> engwar wrote:
> > We're running SourceSafe on an internal server at my company but have
> > been asked to look into running the server component on a webserver
> > outside of our corporate network. We would use either Visual Studio or
> > the SourceSafe client application to check files in/out.
>
> >  Does SourceSafe allow the hosting of the  server component somewhere> > other than the local network? (when I choose 'Add SS Database' the
> > verbiage implies that the ini file I'm looking for is on the local
> > network.)
>
> >  Would the source code be available only to people whom we've set up
> > as users or does hosting it outside of our firewall basically publish
> > our source code?- Hide quoted text -
>
> - Show quoted text -

Hi engwar,

You can also try Dynamsoft SourceAnywhere for VSS, the fastest VSS remote
access software. It is recommended by Microsoft. For more information, please
refer to: http://www.dynamsoft.com

Thanks.

Catherine Sea
Dynamsoft Corporation

-- 
http://www.dynamsoft.com

Message posted via http://www.dotnetmonster.com

Hi engwar,

You can also try Dynamsoft SourceAnywhere for VSS, the fastest VSS remote
access software. It is recommended by Microsoft. For more information, please
refer to: http://www.dynamsoft.com

Thanks.

Catherine Sea
Dynamsoft Corporation

-- 
http://www.dynamsoft.com

Message posted via DotNetMonster.com
http://www.dotnetmonster.com/Uwe/Forums.aspx/mvs-vss/200802/1

Mike:

I've checked with Tech Support, and from what I can tell there's never 
been a bug logged for this?  Did you contact our Tech Support 
department?   Did they ever come to a resolution?

You say you were able to reproduce the problem, although it was 
difficult.  I know it may have been a while since you have used 
SourceOffSite (SOS), but we take reports of this kind very, very 
seriously, as SOS should never cause anyone to lose data.

Since SourceOffSite has been in use by tens of thousands of people, I'm 
sure I would have heard of something as sever as this.  I'd be more than 
happy to investigate further to see if we can help.

Jeff Clausius
SourceGear


Mike {0A6FF490-CF84-4d78-BD85-FF011A0C310C} wrote:
> Be careful with SourceOffSite.  Check their bug fix history and make
> sure they've fixed the following bug:
> 
> I used it around 2002~2003 and I confirmed the following:  My settings
> were set to NOT delete my local data during check in.  I checked in my
> code while I had Windows Explorer open to my source folder.  I saw my
> files disappear one by one as they were checked in.  Then I looked
> into the server and it failed to check them in.  So, I had nothing
> checked in and it deleted my local copy.  VERY Dangerous!
> 
> I do realize that a lot of people have had success with this product,
> but I and my company stopped using it immediately after I was able to
> reproduce that fatal flaw (it was difficult to reproduce as it didn't
> do that every time).  If it weren't for that, I'd highly recommend
> that product.  Aside from deleting any chance of recovery of my source
> code, everything else about it was great, if you could afford the $350/
> seat license fees.  It was fast across our LAN and WAN and it worked
> across the internet (I think).  VSS HTTP is extremely tricky to set up
> and is very very slow, but highly reliable and you don't have to spend
> money on a 3rd party product.
> 
> Good luck with whichever product you choose to go with.
> 
> --------------------------
> Owner/Operator of
> www.MichaelsAttic.com
>

It's been more than 5 years and I was at a different company in a
different city.  They stopped using it because of that reproducible
bug.  The company I work for now does not use it.

As best I can recall, it went like this:

- SOS on a server on our WAN on same machine as VSS 6.0 DB.
- VSS 6.0 Client and SOS client installed on my dev machine.
- In SOS client, I had checked something like "do NOT delete local on
check-in".
- Then when I checked in, it failed AND it deleted my local files.
So, the server copy was gone and so was my local copy.

You may have to turn that check box on and off and check in multiple
times to trigger it.  It's as if the check box didn't stick on
occasion.

I can't recall if we ever reported it.  I'm almost certain that we
did, but again, it was 5 or more years ago.

I hope this information is useful to you.


On Feb 18, 11:37 am, Jeff Clausius  wrote:
> Mike:
>
> I've checked with Tech Support, and from what I can tell there's never
> been a bug logged for this?  Did you contact our Tech Support
> department?   Did they ever come to a resolution?
>
> You say you were able to reproduce the problem, although it was
> difficult.  I know it may have been a while since you have used
> SourceOffSite (SOS), but we take reports of this kind very, very
> seriously, as SOS should never cause anyone to lose data.
>
> Since SourceOffSite has been in use by tens of thousands of people, I'm
> sure I would have heard of something as sever as this.  I'd be more than
> happy to investigate further to see if we can help.
>
> Jeff Clausius
> SourceGear
>
> Mike {0A6FF490-CF84-4d78-BD85-FF011A0C310C} wrote:
> > Be careful with SourceOffSite.  Check their bug fix history and make
> > sure they've fixed the following bug:
>
> > I used it around 2002~2003 and I confirmed the following:  My settings
> > were set to NOT delete my local data during check in.  I checked in my
> > code while I had Windows Explorer open to my source folder.  I saw my
> > files disappear one by one as they were checked in.  Then I looked
> > into the server and it failed to check them in.  So, I had nothing
> > checked in and it deleted my local copy.  VERY Dangerous!
>
> > I do realize that a lot of people have had success with this product,
> > but I and my company stopped using it immediately after I was able to
> > reproduce that fatal flaw (it was difficult to reproduce as it didn't
> > do that every time).  If it weren't for that, I'd highly recommend
> > that product.  Aside from deleting any chance of recovery of my source
> > code, everything else about it was great, if you could afford the $350/
> > seat license fees.  It was fast across our LAN and WAN and it worked
> > across the internet (I think).  VSS HTTP is extremely tricky to set up
> > and is very very slow, but highly reliable and you don't have to spend
> > money on a 3rd party product.
>
> > Good luck with whichever product you choose to go with.
>
> > --------------------------
> > Owner/Operator of
> >www.MichaelsAttic.com

Mike:

I've been unable to recreate this situation using SourceOffSite 4.2.  As 
of right now, I'm closing the issue with our Tech Support dept as I've 
not been able to recreate the behavior.

Thanks for the report.

Jeff Clausius
SourceGear

CSharpner wrote:
> It's been more than 5 years and I was at a different company in a
> different city.  They stopped using it because of that reproducible
> bug.  The company I work for now does not use it.
> 
> As best I can recall, it went like this:
> 
> - SOS on a server on our WAN on same machine as VSS 6.0 DB.
> - VSS 6.0 Client and SOS client installed on my dev machine.
> - In SOS client, I had checked something like "do NOT delete local on
> check-in".
> - Then when I checked in, it failed AND it deleted my local files.
> So, the server copy was gone and so was my local copy.
> 
> You may have to turn that check box on and off and check in multiple
> times to trigger it.  It's as if the check box didn't stick on
> occasion.
> 
> I can't recall if we ever reported it.  I'm almost certain that we
> did, but again, it was 5 or more years ago.
> 
> I hope this information is useful to you.
> 
> 
> On Feb 18, 11:37 am, Jeff Clausius  wrote:
>> Mike:
>>
>> I've checked with Tech Support, and from what I can tell there's never
>> been a bug logged for this?  Did you contact our Tech Support
>> department?   Did they ever come to a resolution?
>>
>> You say you were able to reproduce the problem, although it was
>> difficult.  I know it may have been a while since you have used
>> SourceOffSite (SOS), but we take reports of this kind very, very
>> seriously, as SOS should never cause anyone to lose data.
>>
>> Since SourceOffSite has been in use by tens of thousands of people, I'm
>> sure I would have heard of something as sever as this.  I'd be more than
>> happy to investigate further to see if we can help.
>>
>> Jeff Clausius
>> SourceGear
>>
>> Mike {0A6FF490-CF84-4d78-BD85-FF011A0C310C} wrote:
>>> Be careful with SourceOffSite.  Check their bug fix history and make
>>> sure they've fixed the following bug:
>>> I used it around 2002~2003 and I confirmed the following:  My settings
>>> were set to NOT delete my local data during check in.  I checked in my
>>> code while I had Windows Explorer open to my source folder.  I saw my
>>> files disappear one by one as they were checked in.  Then I looked
>>> into the server and it failed to check them in.  So, I had nothing
>>> checked in and it deleted my local copy.  VERY Dangerous!
>>> I do realize that a lot of people have had success with this product,
>>> but I and my company stopped using it immediately after I was able to
>>> reproduce that fatal flaw (it was difficult to reproduce as it didn't
>>> do that every time).  If it weren't for that, I'd highly recommend
>>> that product.  Aside from deleting any chance of recovery of my source
>>> code, everything else about it was great, if you could afford the $350/
>>> seat license fees.  It was fast across our LAN and WAN and it worked
>>> across the internet (I think).  VSS HTTP is extremely tricky to set up
>>> and is very very slow, but highly reliable and you don't have to spend
>>> money on a 3rd party product.
>>> Good luck with whichever product you choose to go with.
>>> --------------------------
>>> Owner/Operator of
>>> www.MichaelsAttic.com
>

Unfortunately, it's been more than 5 years since this happened.
Here's what I recall:

- VSS 6.0 installed on a server.
- SOS server component installed on same server... don't recall the
version, but it was the latest at the time.
- VSS 6.0, SOS client, and Visual Studio 6.0 installed on client
machine.  Server was Windows 2000 Server.  My desktop was either NT
4.0 or XP... that was close to around the time we upgraded to XP, so I
don't recall which version for sure, but it was more likely XP.
- Working over a WAN from Chattanooga, TN to Portland, Maine.
- In SOS client, I had checked and confirmed a box like "Do not delete
local files on check in".
- Using SOS client, I checked in my project, while having Windows
Explorer opened to my local project folder.
- SOS started "checking in" the files and they were systematically
being deleted from my local machine.
- When it was all done, I don't recall exactly what happened on the
server... whether it deleted them on the server, or they never made it
to the server, but the end result is they were gone from my local
machine AND from the server.

The first time this happened, I thought I must have mistakenly
unchecked the box "do not delete local files on check in".  From that
point forward, I double-verified all of my settings and opened Windows
Explorer (and backed up my files) before checking in and witnessed
this happen 2 extra times.

From that point forward, we never used it again.  I've since upgraded
my career and longer work at that company and have not used the
product since, so sorry that I cannot give any more information than
my 5 or 6 year old recollection.

Note that I'm not asking for support and that I don't need it, since
I'm not a customer.  I will help you where I can though with my
recollections.  I think it's great that you take this type of report
seriously.  I see a later message that you created and subsequently
closed a ticket.  You might want to try recreating the environment I
described above.  I would also recommend having the developers take a
deep look into the code that deletes locally and all conditions that
could cause it to be called.  I would also have them look at the logic
when "delete local" is enabled and to avoid deleting until it is
confirmed that the check in was successful.  Have them look at what
the code does when the check in fails (regarding deleting locally).
Also, have them double-check that the server doesn't falsely report
success on check in when it fails, thereby triggering the client to
delete locally.  It would probably be a good idea to not delete
anything locally until every file in the project is checked in
successfully.  As a developer, a partially failed check in with a
partially deleted project would cause me a lot of headache.

I personally confirmed that these problems occurred and I would feel
very uncomfortable using or recommending SOS until I knew that they
verified and fixed the problem.  As a matter of fact, I'd immediately
buy the product because other than that serious flaw, it was by far a
great solution for slow connections and over the internet
connectivity.  I'm a developer, so I do understand that problems that
are difficult to reproduce are difficult to verify and hence to fix,
so that's why I'm recommending that your developers peer directly into
the code base, regardless of whether you're able to reproduce the
problem.  I have fixed many problems that I was never able to
reproduce without ultimately searching in the code and finding where
it *could* happen and fixing it.  Usually, after finding it in code, I
can then reproduce it because I know exactly what triggers it in the
code.

Of course, it's possible that the problem unintentionally got fixed as
a side effect of other code changes.  So, it might be worth checking
out the version of your source that was publicly available in about
2000-2001.

Hope this information is helpful!
--------------------------
Owner/Operator of
www.MichaelsAttic.com

On Feb 18, 11:37 am, Jeff Clausius  wrote:
> Mike:
>
> I've checked with Tech Support, and from what I can tell there's never
> been a bug logged for this?  Did you contact our Tech Support
> department?   Did they ever come to a resolution?
>
> You say you were able to reproduce the problem, although it was
> difficult.  I know it may have been a while since you have used
> SourceOffSite (SOS), but we take reports of this kind very, very
> seriously, as SOS should never cause anyone to lose data.
>
> Since SourceOffSite has been in use by tens of thousands of people, I'm
> sure I would have heard of something as sever as this.  I'd be more than
> happy to investigate further to see if we can help.
>
> Jeff Clausius
> SourceGear
>
> Mike {0A6FF490-CF84-4d78-BD85-FF011A0C310C} wrote:
> > Be careful with SourceOffSite.  Check their bug fix history and make
> > sure they've fixed the following bug:
>
> > I used it around 2002~2003 and I confirmed the following:  My settings
> > were set to NOT delete my local data during check in.  I checked in my
> > code while I had Windows Explorer open to my source folder.  I saw my
> > files disappear one by one as they were checked in.  Then I looked
> > into the server and it failed to check them in.  So, I had nothing
> > checked in and it deleted my local copy.  VERY Dangerous!
>
> > I do realize that a lot of people have had success with this product,
> > but I and my company stopped using it immediately after I was able to
> > reproduce that fatal flaw (it was difficult to reproduce as it didn't
> > do that every time).  If it weren't for that, I'd highly recommend
> > that product.  Aside from deleting any chance of recovery of my source
> > code, everything else about it was great, if you could afford the $350/
> > seat license fees.  It was fast across our LAN and WAN and it worked
> > across the internet (I think).  VSS HTTP is extremely tricky to set up
> > and is very very slow, but highly reliable and you don't have to spend
> > money on a 3rd party product.
>
> > Good luck with whichever product you choose to go with.
>
> > --------------------------
> > Owner/Operator of
> >www.MichaelsAttic.com

Unfortunately, it's been more than 5 years since this happened.
Here's what I recall:

- VSS 6.0 installed on a server.
- SOS server component installed on same server... don't recall the
version, but it was the latest at the time.
- VSS 6.0, SOS client, and Visual Studio 6.0 installed on client
machine.  Server was Windows 2000 Server.  My desktop was either NT
4.0 or XP... that was close to around the time we upgraded to XP, so I
don't recall which version for sure, but it was more likely XP.
- Working over a WAN from Chattanooga, TN to Portland, Maine.
- In SOS client, I had checked and confirmed a box like "Do not delete
local files on check in".
- Using SOS client, I checked in my project, while having Windows
Explorer opened to my local project folder.
- SOS started "checking in" the files and they were systematically
being deleted from my local machine.
- When it was all done, I don't recall exactly what happened on the
server... whether it deleted them on the server, or they never made it
to the server, but the end result is they were gone from my local
machine AND from the server.

The first time this happened, I thought I must have mistakenly
unchecked the box "do not delete local files on check in".  From that
point forward, I double-verified all of my settings and opened Windows
Explorer (and backed up my files) before checking in and witnessed
this happen 2 extra times.

From that point forward, we never used it again.  I've since upgraded
my career and no longer work at that company and have not used the
product since, so sorry that I cannot give any more information than
my 5 or 6 year old recollection.

Note that I'm not asking for support and that I don't need it, since
I'm not a customer.  I will help you where I can though with my
recollections.  I think it's great that you take this type of report
seriously.  I see a later message that you created and subsequently
closed a ticket.  You might want to try recreating the environment I
described above.  I would also recommend having the developers take a
deep look into the code that deletes locally and all conditions that
could cause it to be called.  I would also have them look at the logic
when "delete local" is enabled and to avoid deleting until it is
confirmed that the check in was successful.  Have them look at what
the code does when the check in fails (regarding deleting locally).
Also, have them double-check that the server doesn't falsely report
success on check in when it fails, thereby triggering the client to
delete locally.  It would probably be a good idea to not delete
anything locally until every file in the project is checked in
successfully.  As a developer, a partially failed check in with a
partially deleted project would cause me a lot of headache.

I personally confirmed that these problems occurred and I would feel
very uncomfortable using or recommending SOS until I knew that they
verified and fixed the problem.  As a matter of fact, I'd immediately
buy the product because other than that serious flaw, it was by far a
great solution for slow connections and over the internet
connectivity.  I'm a developer, so I do understand that problems that
are difficult to reproduce are difficult to verify and hence to fix,
so that's why I'm recommending that your developers peer directly into
the code base, regardless of whether you're able to reproduce the
problem.  I have fixed many problems that I was never able to
reproduce without ultimately searching in the code and finding where
it *could* happen and fixing it.  Usually, after finding it in code, I
can then reproduce it because I know exactly what triggers it in the
code.

Of course, it's possible that the problem unintentionally got fixed as
a side effect of other code changes.  So, it might be worth checking
out the version of your source that was publicly available in about
2000-2001.

Hope this information is helpful!
--------------------------
Owner/Operator of
www.MichaelsAttic.com

On Feb 18, 11:37 am, Jeff Clausius  wrote:
> Mike:
>
> I've checked with Tech Support, and from what I can tell there's never
> been a bug logged for this?  Did you contact our Tech Support
> department?   Did they ever come to a resolution?
>
> You say you were able to reproduce the problem, although it was
> difficult.  I know it may have been a while since you have used
> SourceOffSite (SOS), but we take reports of this kind very, very
> seriously, as SOS should never cause anyone to lose data.
>
> Since SourceOffSite has been in use by tens of thousands of people, I'm
> sure I would have heard of something as sever as this.  I'd be more than
> happy to investigate further to see if we can help.
>
> Jeff Clausius
> SourceGear
>
> Mike {0A6FF490-CF84-4d78-BD85-FF011A0C310C} wrote:
> > Be careful with SourceOffSite.  Check their bug fix history and make
> > sure they've fixed the following bug:
>
> > I used it around 2002~2003 and I confirmed the following:  My settings
> > were set to NOT delete my local data during check in.  I checked in my
> > code while I had Windows Explorer open to my source folder.  I saw my
> > files disappear one by one as they were checked in.  Then I looked
> > into the server and it failed to check them in.  So, I had nothing
> > checked in and it deleted my local copy.  VERY Dangerous!
>
> > I do realize that a lot of people have had success with this product,
> > but I and my company stopped using it immediately after I was able to
> > reproduce that fatal flaw (it was difficult to reproduce as it didn't
> > do that every time).  If it weren't for that, I'd highly recommend
> > that product.  Aside from deleting any chance of recovery of my source
> > code, everything else about it was great, if you could afford the $350/
> > seat license fees.  It was fast across our LAN and WAN and it worked
> > across the internet (I think).  VSS HTTP is extremely tricky to set up
> > and is very very slow, but highly reliable and you don't have to spend
> > money on a 3rd party product.
>
> > Good luck with whichever product you choose to go with.
>
> > --------------------------
> > Owner/Operator of
> >www.MichaelsAttic.com

Mike:

Five years ago, I was working on the Vault Server, so I wasn't on the 
SOS client team at this time.  However, we are investigating issues in 
SourceOffSite for future improvements, and I'm involved with this process.

As I mentioned in my last post, I didn't uncover anything in the latest 
version of SourceOffSite.  The code here has remained stable for a 
number of versions, including SOS 3.5.  I'd be surprised if you were on 
that version or later, as the code here has been tested over and over, 
so it is pretty solid.  We've never had a report of this kind for those 
versions.

Regardless, I'll re-open up the ticket, add an audit of the code for 
checking in files to my currently assigned work items.

Jeff Clausius
SourceGear


Mike {0A6FF490-CF84-4d78-BD85-FF011A0C310C} wrote:
> Unfortunately, it's been more than 5 years since this happened.
> Here's what I recall:
> 
> - VSS 6.0 installed on a server.
> - SOS server component installed on same server... don't recall the
> version, but it was the latest at the time.
> - VSS 6.0, SOS client, and Visual Studio 6.0 installed on client
> machine.  Server was Windows 2000 Server.  My desktop was either NT
> 4.0 or XP... that was close to around the time we upgraded to XP, so I
> don't recall which version for sure, but it was more likely XP.
> - Working over a WAN from Chattanooga, TN to Portland, Maine.
> - In SOS client, I had checked and confirmed a box like "Do not delete
> local files on check in".
> - Using SOS client, I checked in my project, while having Windows
> Explorer opened to my local project folder.
> - SOS started "checking in" the files and they were systematically
> being deleted from my local machine.
> - When it was all done, I don't recall exactly what happened on the
> server... whether it deleted them on the server, or they never made it
> to the server, but the end result is they were gone from my local
> machine AND from the server.
> 
> The first time this happened, I thought I must have mistakenly
> unchecked the box "do not delete local files on check in".  From that
> point forward, I double-verified all of my settings and opened Windows
> Explorer (and backed up my files) before checking in and witnessed
> this happen 2 extra times.
> 
> From that point forward, we never used it again.  I've since upgraded
> my career and longer work at that company and have not used the
> product since, so sorry that I cannot give any more information than
> my 5 or 6 year old recollection.
> 
> Note that I'm not asking for support and that I don't need it, since
> I'm not a customer.  I will help you where I can though with my
> recollections.  I think it's great that you take this type of report
> seriously.  I see a later message that you created and subsequently
> closed a ticket.  You might want to try recreating the environment I
> described above.  I would also recommend having the developers take a
> deep look into the code that deletes locally and all conditions that
> could cause it to be called.  I would also have them look at the logic
> when "delete local" is enabled and to avoid deleting until it is
> confirmed that the check in was successful.  Have them look at what
> the code does when the check in fails (regarding deleting locally).
> Also, have them double-check that the server doesn't falsely report
> success on check in when it fails, thereby triggering the client to
> delete locally.  It would probably be a good idea to not delete
> anything locally until every file in the project is checked in
> successfully.  As a developer, a partially failed check in with a
> partially deleted project would cause me a lot of headache.
> 
> I personally confirmed that these problems occurred and I would feel
> very uncomfortable using or recommending SOS until I knew that they
> verified and fixed the problem.  As a matter of fact, I'd immediately
> buy the product because other than that serious flaw, it was by far a
> great solution for slow connections and over the internet
> connectivity.  I'm a developer, so I do understand that problems that
> are difficult to reproduce are difficult to verify and hence to fix,
> so that's why I'm recommending that your developers peer directly into
> the code base, regardless of whether you're able to reproduce the
> problem.  I have fixed many problems that I was never able to
> reproduce without ultimately searching in the code and finding where
> it *could* happen and fixing it.  Usually, after finding it in code, I
> can then reproduce it because I know exactly what triggers it in the
> code.
> 
> Of course, it's possible that the problem unintentionally got fixed as
> a side effect of other code changes.  So, it might be worth checking
> out the version of your source that was publicly available in about
> 2000-2001.
> 
> Hope this information is helpful!
> --------------------------
> Owner/Operator of
> www.MichaelsAttic.com
> 
> On Feb 18, 11:37 am, Jeff Clausius  wrote:
>> Mike:
>>
>> I've checked with Tech Support, and from what I can tell there's never
>> been a bug logged for this?  Did you contact our Tech Support
>> department?   Did they ever come to a resolution?
>>
>> You say you were able to reproduce the problem, although it was
>> difficult.  I know it may have been a while since you have used
>> SourceOffSite (SOS), but we take reports of this kind very, very
>> seriously, as SOS should never cause anyone to lose data.
>>
>> Since SourceOffSite has been in use by tens of thousands of people, I'm
>> sure I would have heard of something as sever as this.  I'd be more than
>> happy to investigate further to see if we can help.
>>
>> Jeff Clausius
>> SourceGear
>>
>> Mike {0A6FF490-CF84-4d78-BD85-FF011A0C310C} wrote:
>>> Be careful with SourceOffSite.  Check their bug fix history and make
>>> sure they've fixed the following bug:
>>> I used it around 2002~2003 and I confirmed the following:  My settings
>>> were set to NOT delete my local data during check in.  I checked in my
>>> code while I had Windows Explorer open to my source folder.  I saw my
>>> files disappear one by one as they were checked in.  Then I looked
>>> into the server and it failed to check them in.  So, I had nothing
>>> checked in and it deleted my local copy.  VERY Dangerous!
>>> I do realize that a lot of people have had success with this product,
>>> but I and my company stopped using it immediately after I was able to
>>> reproduce that fatal flaw (it was difficult to reproduce as it didn't
>>> do that every time).  If it weren't for that, I'd highly recommend
>>> that product.  Aside from deleting any chance of recovery of my source
>>> code, everything else about it was great, if you could afford the $350/
>>> seat license fees.  It was fast across our LAN and WAN and it worked
>>> across the internet (I think).  VSS HTTP is extremely tricky to set up
>>> and is very very slow, but highly reliable and you don't have to spend
>>> money on a 3rd party product.
>>> Good luck with whichever product you choose to go with.
>>> --------------------------
>>> Owner/Operator of
>>> www.MichaelsAttic.com
>

Very cool!  I have to say:  I am impressed with your willingness to
check into the issue.  The majority of software companies just assume
their code is perfect and won't take problem reports seriously...
especially in an informal setting such as this.  I look forward to the
progress reports...

--------------------------
Owner/Operator of
www.MichaelsAttic.com

On Feb 28, 9:21 am, Jeff Clausius  wrote:
> Mike:
>
> Five years ago, I was working on the Vault Server, so I wasn't on the
> SOS client team at this time.  However, we are investigating issues in
> SourceOffSite for future improvements, and I'm involved with this process.> As I mentioned in my last post, I didn't uncover anything in the latest
> version of SourceOffSite.  The code here has remained stable for a
> number of versions, including SOS 3.5.  I'd be surprised if you were on
> that version or later, as the code here has been tested over and over,
> so it is pretty solid.  We've never had a report of this kind for those
> versions.
>
> Regardless, I'll re-open up the ticket, add an audit of the code for
> checking in files to my currently assigned work items.
>
> JeffClausius
> SourceGear
>
>
>
> Mike {0A6FF490-CF84-4d78-BD85-FF011A0C310C} wrote:
> > Unfortunately, it's been more than 5 years since this happened.
> > Here's what I recall:
>
> > - VSS 6.0 installed on a server.
> > - SOS server component installed on same server... don't recall the
> > version, but it was the latest at the time.
> > - VSS 6.0, SOS client, and Visual Studio 6.0 installed on client
> > machine.  Server was Windows 2000 Server.  My desktop was either NT
> > 4.0 or XP... that was close to around the time we upgraded to XP, so I
> > don't recall which version for sure, but it was more likely XP.
> > - Working over a WAN from Chattanooga, TN to Portland, Maine.
> > - In SOS client, I had checked and confirmed a box like "Do not delete
> > local files on check in".
> > - Using SOS client, I checked in my project, while having Windows
> > Explorer opened to my local project folder.
> > - SOS started "checking in" the files and they were systematically
> > being deleted from my local machine.
> > - When it was all done, I don't recall exactly what happened on the
> > server... whether it deleted them on the server, or they never made it
> > to the server, but the end result is they were gone from my local
> > machine AND from the server.
>
> > The first time this happened, I thought I must have mistakenly
> > unchecked the box "do not delete local files on check in".  From that
> > point forward, I double-verified all of my settings and opened Windows
> > Explorer (and backed up my files) before checking in and witnessed
> > this happen 2 extra times.
>
> > From that point forward, we never used it again.  I've since upgraded
> > my career and longer work at that company and have not used the
> > product since, so sorry that I cannot give any more information than
> > my 5 or 6 year old recollection.
>
> > Note that I'm not asking for support and that I don't need it, since
> > I'm not a customer.  I will help you where I can though with my
> > recollections.  I think it's great that you take this type of report
> > seriously.  I see a later message that you created and subsequently
> > closed a ticket.  You might want to try recreating the environment I
> > described above.  I would also recommend having the developers take a
> > deep look into the code that deletes locally and all conditions that
> > could cause it to be called.  I would also have them look at the logic> > when "delete local" is enabled and to avoid deleting until it is
> > confirmed that the check in was successful.  Have them look at what
> > the code does when the check in fails (regarding deleting locally).
> > Also, have them double-check that the server doesn't falsely report
> > success on check in when it fails, thereby triggering the client to
> > delete locally.  It would probably be a good idea to not delete
> > anything locally until every file in the project is checked in
> > successfully.  As a developer, a partially failed check in with a
> > partially deleted project would cause me a lot of headache.
>
> > I personally confirmed that these problems occurred and I would feel
> > very uncomfortable using or recommending SOS until I knew that they
> > verified and fixed the problem.  As a matter of fact, I'd immediately
> > buy the product because other than that serious flaw, it was by far a
> > great solution for slow connections and over the internet
> > connectivity.  I'm a developer, so I do understand that problems that
> > are difficult to reproduce are difficult to verify and hence to fix,
> > so that's why I'm recommending that your developers peer directly into
> > the code base, regardless of whether you're able to reproduce the
> > problem.  I have fixed many problems that I was never able to
> > reproduce without ultimately searching in the code and finding where
> > it *could* happen and fixing it.  Usually, after finding it in code, I> > can then reproduce it because I know exactly what triggers it in the
> > code.
>
> > Of course, it's possible that the problem unintentionally got fixed as
> > a side effect of other code changes.  So, it might be worth checking
> > out the version of your source that was publicly available in about
> > 2000-2001.
>
> > Hope this information is helpful!
> > --------------------------
> > Owner/Operator of
> >www.MichaelsAttic.com
>
> > On Feb 18, 11:37 am,JeffClausius wrote:
> >> Mike:
>
> >> I've checked with Tech Support, and from what I can tell there's never
> >> been a bug logged for this?  Did you contact our Tech Support
> >> department?   Did they ever come to a resolution?
>
> >> You say you were able to reproduce the problem, although it was
> >> difficult.  I know it may have been a while since you have used
> >> SourceOffSite (SOS), but we take reports of this kind very, very
> >> seriously, as SOS should never cause anyone to lose data.
>
> >> Since SourceOffSite has been in use by tens of thousands of people, I'm> >> sure I would have heard of something as sever as this.  I'd be more than
> >> happy to investigate further to see if we can help.
>
> >>JeffClausius
> >> SourceGear
>
> >> Mike {0A6FF490-CF84-4d78-BD85-FF011A0C310C} wrote:
> >>> Be careful with SourceOffSite.  Check their bug fix history and make> >>> sure they've fixed the following bug:
> >>> I used it around 2002~2003 and I confirmed the following:  My settings
> >>> were set to NOT delete my local data during check in.  I checked in my
> >>> code while I had Windows Explorer open to my source folder.  I saw my
> >>> files disappear one by one as they were checked in.  Then I looked
> >>> into the server and it failed to check them in.  So, I had nothing
> >>> checked in and it deleted my local copy.  VERY Dangerous!
> >>> I do realize that a lot of people have had success with this product,
> >>> but I and my company stopped using it immediately after I was able to
> >>> reproduce that fatal flaw (it was difficult to reproduce as it didn't
> >>> do that every time).  If it weren't for that, I'd highly recommend
> >>> that product.  Aside from deleting any chance of recovery of my source
> >>> code, everything else about it was great, if you could afford the $350> >>> seat license fees.  It was fast across our LAN and WAN and it worked> >>> across the internet (I think).  VSS HTTP is extremely tricky to set up
> >>> and is very very slow, but highly reliable and you don't have to spend> >>> money on a 3rd party product.
> >>> Good luck with whichever product you choose to go with.
> >>> --------------------------
> >>> Owner/Operator of
> >>>www.MichaelsAttic.com- Hide quoted text -
>
> - Show quoted text -