edited files not in pending change set

This forum is now locked, since Gold Support is no longer offered.

Moderator: SourceGear

Locked
nmcalpin
Posts: 38
Joined: Mon Nov 01, 2004 10:06 am

edited files not in pending change set

Post by nmcalpin » Thu Apr 14, 2005 10:18 am

we updated to Vault 3.0.6 a few days ago (from 3.0.1) and are comparing the problems we used to encounter to those we encounter now, and this is one that is still occuring. notes from one of our developers:
Steve: well, at least once my pending change set still didn't include
a file I had edited

Steve: but I've learned to accept that as a fact of life

Nick : this morning?

Steve: yep

Nick : and that's with running the new client?

Steve: yep

Steve: I edited the file with Emacs

Steve: It appeared as 'edited' in the directory view

Steve: but was not on my pending change set
And then later:
Steve: Now I just edited something in BCB and it did not appear in my
pending change set, though its status is 'Edited'.

Steve: It's a minor annoyance in the grand scheme of things, but they
certainly haven't resolved the issue
Any ideas?

ericsink
Posts: 346
Joined: Mon Dec 15, 2003 1:52 pm
Location: SourceGear
Contact:

Post by ericsink » Thu Apr 14, 2005 11:34 am

This situation presents a serious challenge to my general preference for avoiding the use of vulgarity in our forums.


I really want to know what's causing this, so I'm going to ask some questions. Apologies in advance if these questions are redundant or silly:

Is the behavior consistently reproducible?

Under the Help menu, choose About SourceGear Vault. The resulting dialog box says "Version 3.0.6 (2856)", right?

What kind of file system are you using? For example, is it NTFS on a local drive? Is it a remote mounted file system? Is it Samba?

Are you editing just one file and it doesn't show up in the pending change set? Or are you editing more than one? How many?

What version of emacs? I doubt this matters, but I thought I would ask. I just tried editing a file with emacs 21.3, and it worked fine.

Under the Tools menu, choose Options, and click to the "Concurrent Development Style" page. What is the state of the "Require Check Out Before Check In" checkbox? It should be unchecked, right?

What version of Windows is being used on the client machine?

What CPU is in that machine?

How much RAM?

Does your client logfile (%TEMP%\VaultGuiClient.txt) contain anything unusual around the time of the problem? If .NET's FileSystemWatcher class overflows its internal buffer, Vault should report this to the log.

Check your Event Viewer as well, as this error may have been reported there instead if anything went wrong trying to write to the log file.

Was the offending file in the currently selected folder? It sounds like it was, since you said the status was Edited, and that suggests that you had its folder open to check that status.

If you switch away to another app and then switch back, does the file show up in the pending change set?

If you quit the Vault client and open it again, does the file show up in the pending change set?

If you right-click on the folder containing the file and choose Check In, does the file show up in the resulting dialog?

Yes, I'm grasping at straws here -- the changes I made for 3.0.6 were supposed to make sure this problem never happened again, so I really want to know what is going on.
Eric Sink
Software Craftsman
SourceGear

ericsink
Posts: 346
Joined: Mon Dec 15, 2003 1:52 pm
Location: SourceGear
Contact:

Post by ericsink » Thu Apr 14, 2005 11:54 am

Another question:

Did this problem happen just after the client started up?

(When the client starts up, it performs a scan of your working folder. If your working folder contains lots of files, this scan can take a minute or so. Until the scan completes, the file may not show up in the pending change set.)

Or are you saying that you modified a file with the Vault client already running and the Vault client failed to notice the change?
Eric Sink
Software Craftsman
SourceGear

ssalter_chemsw
Posts: 3
Joined: Thu Apr 14, 2005 2:59 pm

Post by ssalter_chemsw » Thu Apr 14, 2005 3:13 pm

> Is the behavior consistently reproducible?

Unfortunately, no. Since it happened twice this morning, it has yet to happen again.

> Under the Help menu, choose About SourceGear Vault. The resulting dialog box says "Version 3.0.6 (2856)", right?

Yep.

> What kind of file system are you using? For example, is it NTFS on a local drive? Is it a remote mounted file system? Is it Samba?

NTFS on a local hard drive which is split into two logical drives (C and D), on a Dell Latitude running WinXP SP1.

> Are you editing just one file and it doesn't show up in the pending change set? Or are you editing more than one? How many?

Just one file, maybe two. Never a lot.

> What version of emacs? I doubt this matters, but I thought I would ask. I just tried editing a file with emacs 21.3, and it worked fine.

21.3.1. And I just tried again and it worked fine for me too. I also made this happen with BCB6.

> Under the Tools menu, choose Options, and click to the "Concurrent Development Style" page. What is the state of the "Require Check Out Before Check In" checkbox? It should be unchecked, right?

Yes, unchecked.

> What version of Windows is being used on the client machine?

Windows XP Service Pack 1

> What CPU is in that machine?

2.2 GHz Intel Pentium 4M

> How much RAM?

1.0 GB

> Does your client logfile (%TEMP%\VaultGuiClient.txt) contain anything unusual around the time of the problem? If .NET's FileSystemWatcher class overflows its internal buffer, Vault should report this to the log.

No such file in my %TEMP% directory.

> Check your Event Viewer as well, as this error may have been reported there instead if anything went wrong trying to write to the log file.

No luck there either. Not a single Vault message.

> Was the offending file in the currently selected folder? It sounds like it was, since you said the status was Edited, and that suggests that you had its folder open to check that status.

The file was not in the currently selected folder while I was editing it. After I was finished and had saved my changes, I had to navigate to the folder in order to check it in. Doing a file diff, history, or opening and closing the Options menu will all make the file pop onto the Pending Change List.

> If you switch away to another app and then switch back, does the file show up in the pending change set?

I'm pretty sure it doesn't, but I will try again next time it happens.

> If you quit the Vault client and open it again, does the file show up in the pending change set?

I'm pretty sure it does, but again, I will try again next time it happens.

> If you right-click on the folder containing the file and choose Check In, does the file show up in the resulting dialog?

In the first version of Vault that we had, you were unable to check it in. Vault would flicker and then pretend like nothing had happened (not even a message in the Messages tab). In the next version (3.0?), this would make the file appear in the pending change list, and you could check it in.

> Did this problem happen just after the client started up?
> (When the client starts up, it performs a scan of your working folder. If your working folder contains lots of files, this scan can take a minute or so. Until the scan completes, the file may not show up in the pending change set.)
> Or are you saying that you modified a file with the Vault client already running and the Vault client failed to notice the change?

It was running when I started editing, and was untouched until after I was finished editing.

Thanks,
-Steve

nmcalpin
Posts: 38
Joined: Mon Nov 01, 2004 10:06 am

Post by nmcalpin » Mon Apr 18, 2005 2:29 pm

Eric,

Is there any more information we can provide? Was the above information sufficient?

thanks.

ssalter_chemsw
Posts: 3
Joined: Thu Apr 14, 2005 2:59 pm

Post by ssalter_chemsw » Thu Apr 21, 2005 1:21 pm

For the record, I haven't noticed this happening since I first reported it. Can't explain why. But I think you can safely let this go for now, and I'll report it again if it ever happens.

Hoping I'm not tempting fate...

Thanks,
-Steve

GregM
Posts: 485
Joined: Sat Mar 13, 2004 9:00 am

Post by GregM » Thu Apr 21, 2005 3:15 pm

Eric, I've seen this recently, but haven't been able to pin this down. We are still using 3.0.5, so if there were changes in this area in 3.0.6, I'll keep an eye out after we upgrade to 3.0.6, hopefully after next week.

nmcalpin
Posts: 38
Joined: Mon Nov 01, 2004 10:06 am

Post by nmcalpin » Wed Apr 12, 2006 10:51 am

Not to bring a topic back from the dead (ok, yes, to bring a topic back from the dead); but this is still a problem with 3.1.7 client/server.

I'm running on an XP SP2 machine. The drives involved (C: and E:) are both NTFS. I am using Borland C++ Builder 5 to edit/develop.

It's a daily occurence that files I change in BCB, even after saving them within BCB, do NOT show up in the pending change list, but the status DOES indicate "edited" in the Vault client. So Vault is aware that they are edited/changed, but the pending change set list is not updated/refreshed.

However, there are a number of triggers that WILL cause the list to update:

1) Tools | Options (as mentioned in a previous post above) and hitting cancel

2) going to Help | About, and then clicking OK, will also cause the pending change set list to refresh right after you click "OK".

I think that Vault client is correctly detecting the changes (as indicated by the status of "edited") but that the pending change set list display simply isn't refreshing.

lbauer
Posts: 9736
Joined: Tue Dec 16, 2003 1:25 pm
Location: SourceGear

Post by lbauer » Thu Apr 13, 2006 8:16 am

If you refresh the file list in the GUI Client (View->Refresh), does that update the pending change set?

You might try updating to Vault 3.1.8. We've had several users report checked out files with Renegade status, checked out files missing from the pending change set, and other odd behavior. It turned out that the Vault Client was reporting had different checkout location values, even though the checkouts were from the same machine.

Not sure if you're experiencing this bug, but it was fixed in 3.1.8, so it's worth a try.
Linda Bauer
SourceGear
Technical Support Manager

Locked