Don't "Require check out ..." edited files not det

Thomas Linder Puls · Post by **Thomas Linder Puls** » Mon Feb 28, 2005 6:28 pm

Due to the bad performance when checking out many files I sometimes work in the don't "Require check out ..." mode.

But this mode is not very good, because I have so many times experinced that not all edited files was detected, and therefore my commit was only "half".

Even finding numerous "Edited" files in the search pane, the "Pending Change" set stays empty. Pressing F5 does not help.

I have found one way to get the perning change set correct. Open options and "tough" the "Require check out..." option. When accepting the options the prending change set is updated correctly. However, this method is rather slow, and it shold not be necessary.

At the very least you should find the full "Pending Change" set, when I press "commit".

dan · Post by **dan** » Tue Mar 01, 2005 8:27 am

Have you upgraded to version 3.0? Version 3 does a better job of keeping the change set and the file list in sync.

GregM · Post by **GregM** » Tue Mar 01, 2005 10:59 am

It's better, but it's still not perfect. Usually, if there are modified files missing, you can either "Refresh" or click on the directory containing the modified files to make them appear in the pending change set. There have been a few times that I've had to restart the client. We're running 3.0.1 now, but hopefully will be updating soon.

Thomas Linder Puls · Post by **Thomas Linder Puls** » Wed Mar 02, 2005 2:55 am

Yes, I use version 3.0.2.

dan · Post by **dan** » Wed Mar 02, 2005 8:27 am

We originally did scan when the commit button was pressed, but this caused performance problems - it can take a very long time (minutes) to scan all working folders for possible changes to files, if you have a lot of working folders defined, so we decided to not scan there (otherwise it would always takes a long time for the actual checkin dialog to come up).

We may want to change this so that when you choose Checkin on a folder from the right click context menu, it does the scan on just that folder and below, which could still take awhile, but would only happen from that invocation place.

mlippert · Post by **mlippert** » Wed Mar 02, 2005 10:45 am

If this is going to be unreliable for whatever reason, I'd like an option somewhere that lets me start a scan so that I KNOW after I've done it, that ALL modified files are in my Pending Change Set list. Perhaps something as simple as doing a Search for all edited files. It is disturbing to see or find a file that has an edited state and yet isn't in the Pending Change Set (I think I've seen this once, but I now have require checkouts turned on).

Mike

Thomas Linder Puls · Post by **Thomas Linder Puls** » Wed Mar 02, 2005 3:56 pm

Well, in all repositories that I use, I have only set the working folder on the very highest level. But I can hardly imagine that it should matter wether folders "inherit" the working folder or define its own.

Anyway, it is absolutely crucial that all necessary changes are committed. I might "commit" and the go on holiday.

Also consider this:

I commit some changes
My fellows "Get Latest"
They build
They get lots of compilation errors
They investigate what the problem is
They come to me and ask whether I have remembered to commit everything
I investigate the files and see that there were some more files that should be committed
I commit them
My fellows "Get Latest" again
They build

And hopefully everything now works (but I cannot be sure).

Please consider what takes most time the scenario above or scanning my disk on commit?

dan · Post by **dan** » Wed Mar 02, 2005 5:02 pm

It isn't the number of working folder assignments that matters, but the total number of files within all local folders that have a working folder assigned to it (whether it is inherited or not, it would have to be scanned).

Always scanning on commit really does introduce huge performance problems, even if it does not show up on your system. This change makes checkin (and therefore Vault) unusable on some systems, even if it doesn't affect your performance that much.

But, we do need to figure out better times to scan:

1. We could do it on a folder checkin from the context menu, as I mentioned above.
2. Mike's idea of doing it while search on edited files has merit - we'd have to check into it see whehter it makes sense in practice.
3. We might just want to introduce an option that says "Scan on Checkin", and the few who experience this problem can turn it on, and live with the performance problems.

We'll need to discuss this here to figure out the best approach. This problem comes up very rarely, but when it does, it is obviously really important, so we need to figure out how to address it.

GregM · Post by **GregM** » Wed Mar 02, 2005 8:44 pm

Dan, I think there's more to this problem than that. There are situations where Vault has obviously detected that the file has been edited, since that is its status in the files pane. However, the file hasn't yet been added to the pending change set. There obviously must be some path where the file gets the "edited" status, but doesn't get added to the pending change set. (I'm still on 3.0.1, but I haven't seen anything listed for .2, .3, or .4 related to this.)

dan · Post by **dan** » Thu Mar 03, 2005 8:31 am

Greg,

Just want to verify: You are seeing a case where the file list says it is edited, but there is no corresponding entry in the pending change set, and you are on 3.0?

In 3.0, when you click on a folder in the tree, and it has a working folder, it does a quick scan to update the status of the files, then updates both the file list and the pending change set. However, it doesn't do this recursively. So, yes, we would be very interested in a case where you can see a file as edited in the file list, but does not exist in the pending change set.

GregM · Post by **GregM** » Thu Mar 03, 2005 9:18 am

Dan, that's correct. The next time I see this, what information do you want me to capture?

sterwill · Post by **sterwill** » Thu Mar 03, 2005 9:30 am

I'm trying to reproduce this kind of problem in a development environment, and I haven't been able to edit a file so that Vault doesn't make a pending change set item for it.

Are there specific editors that seem to cause this problem more than others? Are there any other special circumstances when this happens?

Thomas Linder Puls · Post by **Thomas Linder Puls** » Thu Mar 03, 2005 9:48 am

This is the situation in which I have encountered the poblem.

I make a copy of a complete subtree (my project), and make it writable.
Then I make really many updates in that copy (I need to do a lot of global updates).
Then I use BeyondCompare to copy the changed files back to the working folders.
And then I commit the changes

But many times Vault have not discovered all the changed files, and therefore only some of them are comitted.

Both before and after the commit I have tried to search for "Edited" files. It does not take long time to compute. But unfortunately the files that Vault find as "Edited" are not added to the pending change set.

If I double click on one of the files in the search result, I go to that folder, and here the status is shown as "Edited", but the files are still not added to the Pending Change Set (I.e. this is the same as GregM experiences).

GregM · Post by **GregM** » Thu Mar 03, 2005 10:19 am

I think it's usually been with beyond compare for me as well. When the destination file is read-only, beyond compare will ask you if you want to overwrite, but the new file will be read-only as well. Perhaps that has something to do with it.

dan · Post by **dan** » Thu Mar 03, 2005 12:48 pm

OK, good news - using Beyond Compare was a good clue. We think we've found a way to trigger this bug using a Series of Unfortunate Events (that don't even require you to be an orphan with an Uncle who's after your money).

If you use Beyond Compare, or another editor such as Word, that creates a temporary copy of a file, then deletes the original and renames the temp copy to the original name on save, and if you are in a working folder that is inherited, and you have the Requires Checkout option OFF, then the event that gets passed to Vault from .Net includes extra path information that is not usually included, and we were not generating the correct path to the file that was edited, causing it to not be added to the pending change set.

Also, Greg, it turns out I was wrong about a scan happening when a folder is selected (to automatically put the file in the change set). The scan on a folder happens when you to press F5 (refresh) and then it syncs up with the change set.

In any case, we will get this fixed ASAP, and get a 3.0.5 out as soon as we can, since it is really important to always have a correct pending change set.