RE: Retrieving Reposity Structure....

Shaw,

It seems we do have some sort of problem, and it looks like the problem
started after we upgraded to Vault 1.2.3

I'm not sure that Vault is getting whole repository at the start of each
session anymore. But one thing is for sure..it takes nearly five minutes to
make connection, and it spends all almost all that time at the "Retrieving
Reposity Structure...." step.

This morning, before any of us started work, we checked the modified date of
our CacheMember_Repository files. It was marked sometime in the late
afternoon yesterday..when shutdown our PC's and left work.

I then started up my pc, and logged into the Vault client like normal...and
it sat there and did something for several minutes once it hit "Retrieving
Reposity Structure....". Everyone else had the same problem too.

Once our sessions are established, we can shut down Vaul, and start it back
up again..and we'll be in our repository in just a few seconds. If you let
the session timeout (20 minutes or so), you have to go through the
"Retrieving Reposity Structure...."  process again.





-----Original Message-----
From: Shaw Terwilliger [mailto:[email protected]]
Sent: Tuesday, January 27, 2004 10:51 AM
To: Brandon Casci
Cc: [email protected]
Subject: Re: [vault-list] Retrieving Reposity Structure....


Brandon Casci wrote:
> Since then it appears that Vault needs to retrive the ENTIRE repository
> structure at the start of each new session.
> 
> Has anyone else had this problem or am I imagning this?

Unlike most of the other cache files, this one can be really large, and
Vault only writes the repository structure file under certain conditions. 
When it retrieves the structure on login, it checks to see if there's a 
structure already on disk.  If there is, the file isn't written at this 
time.  If there's no file on disk, the structure is written then.

Later, on client exit, the file on disk is checked (again).  If the 
repository structure in memory is newer than the one on disk (the header
of the disk file is read and compared), the disk file is overwritten.

So if the Vault client is exiting abnormally (killed process) or perhaps
you're using the IDE client and it's exiting abnormally (maybe Visual
Studio isn't letting us logout?), the file may not be written on exit,
but should have been written when it was first retrieved.  You can open 
the directory with the cache member files and watch for their creation 
when Vault runs.  If they're never created, I'll try to track down 
other possibilities.

-- 
Shaw Terwilliger <[email protected]>
SourceGear LLC

Get the latest news on SurfControl and our products,
subscribe to our monthly e-newsletter, SurfAdvisory at:
http://www.surfcontrol.com/resources/surfadvisory/surfadvisory_signup.aspx

*********************************************************************
The information in this email is confidential and may be legally
privileged. It is intended solely for the addressee. Access to this
email by anyone else is unauthorized. If you are not the intended
recipient, any disclosure, copying, distribution or any action taken
or omitted to  be taken in reliance on it, is prohibited and may be
unlawful. If you believe that you have received this email in error,
please contact the sender.
*********************************************************************
SurfControl Inc.
100 Enterprise Way, Suite A110
Scotts Valley, California 95066
831-440-2500