File status problems

[robindch]

In the office back home we use sourcesafe 6 and sourceoffsite 4.2 to access our code when any of us are travelling. My daily back up routine mirrors files from my main development machine (source, mail etc) to my laptop with ViceVersa from TGRMN. I now have my laptop with me in Indonesia on a client site and every file in the source tree view is marked with one dangerous looking status or another ('renegade', 'needs merge' etc). When I do a file compare (select a folder, press ctrl+F), SourceOffsite correctly determines that all files are identical between my laptop and home, but then never reverts the dangerous-looking status markers and then whinges about wanting to overwrite, prompt-overwrite, or automatic-merge my files when I attempt to check them out. I know the files are the same, because it's just told me so, so how come it doesn't remember this when I attempt to check them out?

Also -- I don't know about the internals of SourceOffsite -- but how come SourceOffsite doesn't calculate a local and remote file's CRC (or whatever) and compare the CRC's rather than seeming to download the whole file and compare it that way? I'm at the end of a very long, thin and wobbly straw here in Jakarta and this process of comparing files takes ages and the local gateway is anything but reliable.

I need hardly add that this is a trifle annoying.

[lbauer]

SourceOffSite uses both version numbers and a client-side cache files to determine the status of local files. This cache file is called databaseX.sos and is located in the user's application data folder. (X would be replaced with 1, 2, etc, enumerating each database served by the SOS server.)

When you retrieve a file from the SourceOffSite server, the cache file notes the time that the file was received. If the timestamp of the file in the local working directory changes from the retrieval time, the SourceOffSite client assumes there has been a change to the file. It then becomes a renegade if it is not checked out, or edited if the file has been checked out. It might become needs merge if someone has checked in a change to that file into the database or if it's just confused.

If you simply update files in the working directory without doing a get from the SOS server, file status can become confused, even if the files are exactly the same. This is because the timestamp has changed for the files retrieved outside of SOS.

While SourceOffSite does have the ability to use CRC's, this is only to determine the status of "unknown" files and not files that are renegade needs merge, et cetera. We do have a feature request logged for this; however this functionality would greatly slow down SourceOffSite.

If you plan to travel, your best bet is to do to get latest with the SourceOffSite client, or with an automated get using the commandline client and -Soshome parameter. See soscmd.txt, the documentation for the commandline client, in the SourceOffSite GUI client directory.

[robindch]

Thanks for replying so quickly -- much appreciated.

If you simply update files in the working directory without doing a get from the SOS server, file status can become confused

Yes, I'm aware of that. But the issue is that when SourceOffsite verifies that all files are identical in a folder, it still says that they're different -- it would be very useful indeed if it could update its own out-of-date local database when it determines that the files are identical.

As it stands, I am unable to use SourceOffsite because every one of the thousands of files in my project tree is marked renegage/needs-edit/etc and I simply don't have the time to go through every file in every folder, fixing each one-by-one. I should add that SourceSafe simply checks the file-attribute and my backup method doesn't cause SS any problems so it's surprising that it causes SOS problems!

Finally, as SOS isn't working, I'm having to email source changes home and hoping that somebody can work out what to do with them there. This isn't really quite what I was expecting to have to do with an internet-enabled SS provider.

While SourceOffSite does have the ability to use CRC's, this is only to determine the status of "unknown" files and not files that are renegade needs merge, et cetera [...] this functionality would greatly slow down SourceOffSite.

I don't immediately see how -- the server-side can hash the server-side file quickly and the client-side can hash the client-side. Both operations are fast, and with the hashes calculated, only the hashes need to be pumped up and down the line, not the entire file, as at present. Our SS database contains a few large files and verifying certain folders can take ten or fifteen minutes, even when the internet connection manages here manages to stay up for long enough.

I'd really appreciate you looking into some solution for the first issue, as it's defeated the purpose of SOS for me, at least.

thanks.

[lbauer]

I'll pass your suggestions on to our developers and add them as feature requests in our features database.

[ssccoorrcchhiioo]

I'll pass your suggestions on to our developers and add them as feature requests in our features database.

A quick search of this forum suggests that this has been an issue for at least 3 years now (see : GetLatest doesn't "use checksums..." from June 2004). So either nobody is telling the developers or the developers don't feel like writing the code!

Clearly there are a number of users who initially populate a directory by means other than SOS GetLatest. The reasons and methods are many and varied but the end result is the same - SOS downloads files over the top of identical files and this is a big issue for people with restricted and/or unreliable bandwidth.

The fact that it might slow SOS down for users who don't need this feature can be dealt with by setting it as an option. And the argument that adding additional realtime (non-cached) checks would make SOS as slow as using VSS over VPN is nonsense - you would have to write out my source code by hand and send it by courier to my head office to make it that slow.

James