Soscmd gets files it doesn't need to

Bill Medland · Post by **Bill Medland** » Mon Sep 19, 2005 9:14 pm

(I've just installed 4.1.2 so now soscmd doesn't totally trash the statuses but...)

I am accessing a quite large database (of the order of a gig to do a full get). Currently firs thing in the morning I do a "Refresh Project Tree" which takes a minute or so, and then I do a full recursive get and walk away for half an hour. It takes about half an hour to get the file lists and about a minute to get the actual updates.

What I want to do is schedule a script to do that early in the morning before I start.

I have just tried, to see if it is going to work. I do a recursive get on a subproject, with verbose on, and watch it get files that I know are up-to-date. I even did it repeatedly and still it was getting them.

(At least, I presume that:
"Got file <workdir>\<filename>"
indicates that it actually transferred the file.)

However if I do the same get through the GUI it knows not to get anything.

Any idea what is going on?

lbauer · Post by **lbauer** » Tue Sep 20, 2005 8:42 am

Are you using the -soshome parameter? When you use this, the CLC references the the SOS database cache file and should then behave the same as the GUI client. See soscmd.txt in your SOS Client directory for documentation on this.

Bill Medland · Post by **Bill Medland** » Tue Sep 20, 2005 10:06 am

Yes Linda.

I am setting the environmental variable SOSHOME to c:\Documents and Settings\<my name>\Application Data\SourceGear\SOS
I am also using -soshome %SOSHOME%

The command is sitting in a batch script and is

"%SOSCMD%" -verbose -nocompress -soshome "%SOSHOME%" -server %SOSSERVER% -name %SOSUSER% -password %SOSPW% -database %SOSDB% -project $\ -command GetProject -recursive

in %SOSHOME% is the following structure of files and directories
servers
servers\<tcpip address>
servers\<tcpip address>\index.sos
servers\<tcpip address>\database[1-6].sos

According to index.sos it is database3.sos that should be used.

I believe that the server might still be running 4.0 or 4.1.0 but presumably that doesn't matter since the GUI client handles it OK.

(Can I get the server version or protocol version from the client end without bothering our staff at the server end?)

Any other suggestions?

bfinney · Post by **bfinney** » Tue Sep 20, 2005 2:26 pm

It's definitely getting the files - skipped files produce a message something like "File is up to date: (filename)". Is the .sos file updated after the command exits? If not, the CLC isn't able to read the cache, but I can't hazard a guess as to why at this point.

I was able to force the cache to be ignored by locking the .sos file. Is it possible that something else is using it (i.e. the GUI clinet or an IDE)?

Guest · Post by **Guest** » Tue Sep 20, 2005 3:01 pm

Yes, it is changing the date of the database3.sos and also its size.
(And it doesn't get ALL files; just lots. Some it recognises as OK)

Bill Medland · Post by **Bill Medland** » Tue Sep 20, 2005 6:53 pm

Ah well.

Discarding and rebuilding the database3.sos seems to be solving it. Let's see how long it lasts.

bfinney · Post by **bfinney** » Wed Sep 21, 2005 9:05 am

Thanks for the update. I still plan on bashing on this for a while, but it's slid down the priority list a bit since you've gotten around the problem.

I would suggest adding a delay between the getprojecttree command and the get in your script - a sleep of 60 seconds or so is probably overkill, but wouldn't hurt.

Bill Medland · Post by **Bill Medland** » Wed Sep 21, 2005 11:10 am

GetProjectTree? I wasn't bothering with it. I was just running off the cache as it stood. Does that explain it being extremely slow?

Actually I have given up. I tried running a full get but halted it after an hour or so when it had only got 10% of the way through. From what I see in the verbose output soscmd is using a different method than that used by the GUI. It seems to be asking about each file one by one rather than getting the details first and figuring out for itself which ones to ask about. Is that right?

bfinney · Post by **bfinney** » Thu Sep 22, 2005 8:14 am

Sorry, I misinterpreted something you wrote in your first post - I was assuming that you were refreshing the project tree through the GetProjectTree command rather than from the GUI client.

I won't make a bit of difference in terms of speed, though. The CLC does in fact request one file at a time.