Pending Change Set in CVS Mode is not up to date

PACEGMBH · Post by **PACEGMBH** » Wed Oct 19, 2005 3:28 am

Hello,

we are working in CVS mode and have the problem, that the pending change set is rarely up to date. Only at start up SGV (3.1.2) retrieves the pending changes correctly.
The only way out for us to identify local changes for sure is to search for changed files (which works fine). Unfortunately the search result does not influence the content of the pending change set. So please
- fix the problem that changes are not recognized or
- introduce an explicit rescan option to force an update (e.g. F5 on the desired repository folder wit a recursive scan) or
- incorporate the search results to the pending change set page

Is there another way to work around this problem?

lbauer · Post by **lbauer** » Wed Oct 19, 2005 8:10 am

We could use more information. Are you using the Vault GUI client or integration with Visual Studio?

Can you give us some steps to reproduce? For instance what operations were you doing, what was actually added to the pending change set and what did you expect would be added?

lbauer · Post by **lbauer** » Wed Oct 19, 2005 8:47 am

Also, what version of Vault are you using?

PACEGMBH · Post by **PACEGMBH** » Thu Oct 20, 2005 9:11 am

I'm using the vault client (3.1.2 and the server of the same version), no studio integration.
I'm developping C++ with visual studio 2003. As I said I'm working in CVS Mode. My setings are attached.
I tried to reproduce the problem in another repository but it in this case everything worked fine. How ever, in my workung repository we have the problem and it is verry error prone to work this way. Perhaps this is a matter of the repository size. Here are some facts:
The repository has 2200 revisions, 9500 files and 950 folders. The tree size is about 150 MB.

we are working on different folders at the same time. Changes are only recognized,
- if we perform an action directly in vault (add, delete, F5 explicitly on the selected folder)
- change the options from recognition via date or CRC (we need CRC because many files cahnge their date but not the contents...)
- restart the vault client.
only very rarely all changes are recognized.

What else can we do?

Thanks a lot.

PACEGMBH · Post by **PACEGMBH** » Fri Oct 21, 2005 6:41 am

One thing which is different in my test repository is, that I'm using there the Client GUI only, whereas in the production environment we ar using a mix of command line client and client GUI. Typically we get via the command line and merge/commit via the GUI. Could this be part of the problem?

Best regards.

Carsten.

dan · Post by **dan** » Fri Oct 21, 2005 7:16 am

One thing you could do is turn on client logging and see if there are any errors that get reported as part of scanning or the watcher thread that is supposed to update the pending change set when files change in working folders.

See http://support.sourcegear.com/viewtopic.php?p=7806#7806 and turn on both the "watcher" and "wf" logging classes (or just "all", but that may output more info than would be useful).

PACEGMBH · Post by **PACEGMBH** » Fri Oct 21, 2005 8:19 am

I have added a log file with 'all' classes logged.
Additionally two screen shoots with the differnce between the status search (any Status) and the pending change set.

Thaks & best regards,

Carsten.

dan · Post by **dan** » Fri Oct 21, 2005 8:32 am

The log doesn't report any watcher errors. Can you make a modification in a file somewhere that doesn't update the pending change set, and then look in the log for a "watcher" entry and see if there is one at the time the file was saved?

PACEGMBH · Post by **PACEGMBH** » Fri Oct 21, 2005 9:09 am

This exactly what I've done. I have made two modifications, one that leads to a merge conflict, and they have been found correctly by the status search, but do not show up in the pending change set. Sometimes it helps that I restart the client, but not always...
in the log I found (what could be the related entry, but Im not sure)
21.10.2005 16:11:48 <wf>: [Watcher:2800] wf D:\Projects\2.2b_release\modules\cabin\src\drawings mutex locked
21.10.2005 16:11:48 <mutex>: [Watcher:2800] Released mutex 1928
21.10.2005 16:11:48 <wf>: [Watcher:2800] wf D:\Projects\2.2b_release\modules\cabin\src\drawings mutex released
21.10.2005 16:11:48 <wf>: [Watcher:2800] wf for D:\Projects\2.2b_release\modules\cabin\src\drawings created
21.10.2005 16:11:48 <watcher>: [Watcher:2800] Had 2 notifications, 0 changes

dan · Post by **dan** » Fri Oct 21, 2005 12:05 pm

We'll have to figure out why the notifications that are received are not being processed.

Email me your contact info and I can setup a special build with more logging in it that should help figure it out.

dan · Post by **dan** » Fri Oct 21, 2005 12:10 pm

I just noticed something - the GUI client in the screenshot is not displaying a working folder for the folder you have selected, which could be why the notifications are not being noticed. However, it is reporting a status on the files, so there must be some state information retained the by the client.

Has your client cache been partially deleted?

Also, is this the only machine where you are seeing these errors? It might somehow be related to client state files.

PACEGMBH · Post by **PACEGMBH** » Mon Oct 24, 2005 2:38 am

The working folder is set in the folders below. Never the less, this also might be a part of the problem. We are using a directory and repository structure, which is perhaps a bit unusual.
We have multiple folders in the repository with the layout
$1a
-\2b
-\2c
-\2d
with more subfolders. Most of these folders contain files, and the files are are uniqe for the project.
Multiple projects have the same working directory. So we get files from different repository folders into the same directoy on the disk. The support of this directory structure was one of the main reasons why we selected source gear in favor of subversion.
The problem occurs on all client computers.
I will contact you directly to obtain the more verbose version.

Best regards,

Carsten.

dan · Post by **dan** » Mon Oct 24, 2005 7:54 am

That is probably the issue. Although nothing prevents you from using the same working folder for multiple Vault folders, strange stuff like this is likely to happen. Can you explain why its necessary to have multiple folders pointing to the same working folder?

Also, can you send me an example of which folders at which level are pointing to which working folders? I can probably reproduce this here then.

Thanks

PACEGMBH · Post by **PACEGMBH** » Mon Oct 24, 2005 9:27 am

Hi dan,

From historical reasons all our projects use this paradigm. We have a lot of this stuff (originally handled in SourceSafe) and this was one of the key criteria when we selected a better 'safe' for our sources. To rework all the structure was an effort we did not want to invest.

Attached you find a subset of 3 Projects. Each containing the same structure at the top level. Unzip them into 3 separate folders. Add them into 3 folders in fault. Define a new working directory for them and get them all into this directory. Subsequently changes are only rarely recognized by the pending change set.

Best regards,

Carsten.

dan · Post by **dan** » Mon Oct 24, 2005 12:32 pm

OK, I've reproduced this here, but the bad news is that there isn't much we can do about it in the short term.

If you define the same working folder for multiple Vault folders, it will only automatically find edited files in one of those Vault folders - the others will not match what it thinks the file path should be, and it will fail due to the design of watcher class, which isn't easy to fix.

Vault doesn't officially support this mode of operation, so I'm sorry that you had the impression that it did. It doesn't stop working entirely, but there are a number of issues related to doing it, and this is one of them.

However, there may be a workaround that is acceptable - when you checkin, right click on the parent folder, and will invoke a file system scan before bringing up the checkin dialog for the working folders within that root folder. This will ensure that anything underneath that node that is edited will be included. Also, you can invoke checkin from here as a way to refresh the pending change set, and then cancel the dialog if all you want is an updated pcs.

Hope this helps