Incorrect status (the other way around)

Bill Medland · Post by **Bill Medland** » Wed Jun 27, 2007 11:29 am

(I of course also have the usual problems of files being reported as renegade when they aren't, but I live with it).

I have just been again embarrased due to SOS (on Windows) telling me that a file is current when it is not. I can even do a diff and see the difference and still it is marked as current. Even worse, if I do a get/overwrite it still doesn't update the local copy.

I am running 4.1.2 client and server.

Is this something that would be fixed by upgrading to 4.2?

Beth · Post by **Beth** » Wed Jun 27, 2007 3:27 pm

Are you using IDE integration? If so, then I'll need to change my answer a bit.

If you're just using SOS, then it sounds like your cache could possibly be out of sync or you could be looking at a file in the wrong location (double check your working folder settings). To Clear Your Client Side Cache, you will just remove the *.sos files from disk. More information can be found here: Clear Cache.

Upgrading to 4.2 shouldn't hurt anything, but I'd still say to clear the cache. You may have to reset your working folders again after the clear.

Bill Medland · Post by **Bill Medland** » Wed Jun 27, 2007 5:46 pm

That's what I feared.

So what is going to be the penalty? Will all files end up with unknown status resulting in checksums being used to check all files or will the whole tree end up being fetched ?

Beth · Post by **Beth** » Thu Jun 28, 2007 7:27 am

Yes, it will have to rebuild it which could take a while depending on the size of the tree and you'll have to reset working folders.

You didn't mention if there's IDE integration going on here. That makes a difference in my answer.

Again, you might want to check and see if you have multiple copies going on. You can delete that file from your working folder and try a Get. If it doesn't end up in your working folder again, then that file is not set to go where you are thinking.

Bill Medland · Post by **Bill Medland** » Thu Jun 28, 2007 8:16 am

There isn't supposed to be IDE integration going on but I might accidentally have used it at some point.

Thanks for your help.

Actually I guess I didn't stress what I was asking correctly. Of course the database is going to have to be rebuilt; what I was asking is which way it would be rebuilt:
1. Set everything to unknown status and then use checksums to figure out unknown status (which would be faster)
2. Refetch everything explicitly and then we know.

Anyway I will probably do a full refetch sometime soon.

(Actually that leads me into a couple of things:
1. Technical understanding: Regarding the discussion on why SOS doesn't use the checksums more. I presume that the SOS server actually has to get the file out of sourcesafe and checjsum it; I presume the SourceSafe component is not storing that information in the sourcesafe database). Thus there is a penalty for calculating the checksum on the server
2. What SOS does NOT do for me. I would dearly love the ability to use SOS to have a reasonable way of keeping a clean local copy of the current state of the code tree, updated at night when the internet et.c is not busy. Why is that not possible (under Linux especially)?
a. The command line client uses slower techniques than the UI client
b. It does not have a way of flagging files that exist in the filesystem but not in the sourcesafe database
c. There is no option to request thorough checksum-based verification of version and I have too often seen cases where the IDE gets the status wrong so I cannot believe it.
Just some useful information if you are ever intending doing a new version.

Thanks anyway; SOS is certainly invaluable to me even as it is.

Bill

Beth · Post by **Beth** » Thu Jun 28, 2007 3:17 pm

On the first two questions on having the cache rebuilt, it shouldn't make a difference. Just as long as it gets recreated.

On the other questions.

1) It's a question of speed.

2) By a clean local copy, do you mean as in your working folder? You can use the command line client in a script and schedule that script to run at a set time.
a) I'm not sure exactly what you are asking here.
b) I can put in a feature request, or if one already exists, I'll add your "vote"
c) Have you tried to show differences? If you select at the file level, you will get down to the exact in-file differences.

Bill Medland · Post by **Bill Medland** » Thu Jun 28, 2007 4:15 pm

Hi Beth

FYI only

1.
I saw a discussion somewhere on your lists discussing the use of checksums rather than or as well as file dates to check status. The poster was wondering why it was regarded as a speed issue. I was just wondering about the techicalities at the server end, basically because I am nosy:
For the UI technique of matching up the client file against what is in SourceSafe there are several possibilities that I can see.
a. SourceSafe stores the checksum of the file and returns it to the SourceOffsite server along with the date/time information. The SourceOffsite server has insignificant extra work to do but the client has to checksum the file. Slight client penalty.
b. SourceSafe stores the checksum but SourceOffsite must make a second query to get the iinformation. A little extra work at the server end.
c. SourceSafe does not actually store the checksum and does not provide an API to calculate it. The SourceOffsite server must actually "get" the file and calculate its checksum (which it could possibly cache at the server end). That is quite a significant amount of work at the server end as well as the calculation at the client end.

2. What do I mean by a local copy?

The overall aim is to prove the buildability of the current source in the SourceSafe. One of the main problems then is catering for files in the working directory that are not in the SourceSafe. Are they there because they were generated or because they have been deleted from the SourceSafe? If they are remnants from a deleted file then the source may appear buildable when it is not.

So what I am looking for here is to have a local working directory that contains only the source from sourcesafe. To build one copies that locally and then builds the copy. To check that the working directory contains nothing extra we need a report or something; that is the missing feature. (Under schemes like CVS we can list files that may be expected in the directory and anything else is flagged)

a. It's an observation, not a question. It explains why I cannot use the command line client to do the things you would expect me to use it for. I've already posted about that elsewhere. It's why first thing in the morning I update my working code on Windows using the UI; it takes about 20 minutes (almost entirely just getting the file lists). I have never successfully done it with the command line client. (However I use the command line client overnight on Linux to get a fresh copy of a very small subset of the source; about 50MB I think).

b. Thanks

c. (I of course meant UI, not IDE).
Of course I can select a file and do a diff and it will show me the differences. But that is not acceptable. I can't do that for every file in the project; It would be faster to throw the local copy away and refetch it.
So why don't I just do it for the ones that are flagged as not blank-status? Because the whole issue is that I don't trust the blank status. I don't know why the cache gets damaged but it does. I don't know why I have files with a blank status even though diffing them shows difference, but it does.
So when I do a build and the build fails but when other people do a build and it succeeds I want a THOROUGH SLOW way to check that I TRULY do have a correct copy of the SourceSafe code and I would hope that a checksum-based method would be faster then refetching. Anyway in a moment I will do the experiment.

Just FYI