Feature Request: History Query Filter/Sort, Action Checkout

[PoleVault]

I am using Vault 4.1.0.16216.
I am having trouble with users working on items without checking them out, but I can't see when items were checked out using the "Actions" tab of the "History Query Filter/Sort" popup form.
I get emails listing what items were worked on this week, but a some of the items are still the version from last year.

Can you please add "Check Out" to the history that is recorded? and add it to the choices on the "Actions" tab of the "History Query Filter/Sort" popup form?

This would add more control to my source control. I want to be able to verify that they follow the pattern of Check Out, Modify, Check In.

Thanks.

[jclausius]

You will not find an option for Checkouts on the history tab because a checkout does not result in any kind of historical record.

However, you can find this within the Vault GUI client. Have you tried the "Search" tab? It has the ability to find checked-out items in the repository tree.

[PoleVault]

You will not find an option for Checkouts on the history tab because a checkout does not result in any kind of historical record.

However, you can find this within the Vault GUI client. Have you tried the "Search" tab? It has the ability to find checked-out items in the repository tree.

Jeff,
I am able to find the items that are currently checked out, but if users are not checking things out while they say they are working on them I can not verify it.

I specifically asked for the checkout to be placed in the history so I can do this.

Instead of a Vault that implies a secure place for storage at a bank, I am experiencing something more like a "screen door on a back porch" Without the means to verify when/if users are checking things out I can not guarantee they are following the procedure of Check Out, Modify, Check In.

I think some are doing the following: Modify all day, Check Out, Paste in changes, Check In. I have seen the developers describe that they have been working on things all day and an hour before they leave nothing is checked out. Then a half hour before they finish, they suddenly check in a long list of items that could not possibly have modified in just half an hour.
By doing this, they are not preventing others from modifying the same item that they are working on all day and the source control is not working.

Any help would be appreciated.

[jclausius]

I think I see now. You have a policy in which you want to make sure people are using Vault before they start modifying any files. Is that correct?

I assumed you were wanting to see checkouts in-line with history which wouldn't really work. Instead you would like a "Checked out" report that shows what files are checked out, by which user, and at what time.

While there is nothing that can do that currently within the system, you could use a SQL reporting tool to look at the info within the databases. You would look at the database tables for sgvault.tblcheckoutlist, sgvault.tblrepositories, and sgmaster.users. The information you seek will be found there, and could be used to generate a report of the current list of checked out files.

[jclausius]

I am able to find the items that are currently checked out, but if users are not checking things out while they say they are working on them I can not verify it.

Note, even with the report I mentioned in my previous post, if your users are not using the system to check out files they working on, the report will not be of any use. Except maybe to say that an empty report shows no one is using checkouts.

[jclausius]

Another option you may wish to explore would be to place the Vault Server into "Debug" logging mode. The data stored within the Vault Server log files may also give you the information you seek.

HTH

[PoleVault]

I think I see now. You have a policy in which you want to make sure people are using Vault before they start modifying any files. Is that correct?

I assumed you were wanting to see checkouts in-line with history which wouldn't really work. Instead you would like a "Checked out" report that shows what files are checked out, by which user, and at what time.

While there is nothing that can do that currently within the system,....

I don't want a "Checked Out" report. At any given moment it does not really matter exactly what files are checked out.

What I want is "Checkout" to be added to the history of each file and I want to be able to see it when I right-click on a file, left- click on "Show History", click on the "Actions" tab.
On a file I want to see Created, Checked Out, Checked In, Checked Out, Checked In....

It might also be good to show when a Checked Out was removed, but if "Checkout" is not going to ever be placed in the history, please just say that and I will stop trying to clarify this.

Thanks.

[jclausius]

I'll log your feature request.

My earlier posts were to point the way if you wanted to gather the information for yourself.

[PoleVault]

Thanks Jeff,

Sorry for the confusion, I was only trying to give the background to help justify the request. I know it sounds odd because if everyone uses the Vault like they should, then the feature is not needed. I also thought it might help to get feedback on how people might be using it in a way you didn't expect. I get those kind of surprises in my own development.

[jclausius]

No problem.


Do you mind if I post a couple of follow-up questions?

Could you elaborate on :

- "Modify all day, Check Out, Paste in changes, Check In."

Could you describe the process of "Paste in changes"?


- "By doing this, they are not preventing others from modifying the same item that they are working on all day and the source control is not working."

The Vault client is designed to work in a multitude of different scenarios, exclusive locks, shared locks, and cases where file locks are not even used. For example, with mergeable files changes to a single file (in different areas of a file) can result in a more efficient development process when used with auto-merge. Have you looked at the other development styles?

[PoleVault]

Here is some of the raw description of what has been happening:

We will checkout what went wrong. Probably we have modifed that report in our local project and then checked out sourcevault and updated that file there before taking a Get Latest Version from Source vaut and updating our local project.

We follow the method you have given below for updating source vault. But I guess the team member would have failed to do a Get Latest Version and then start making changes in the local machine.

For now we will look at the last checkin by you on that file in source vault and roll back to that version latter include the changes that we have to do futher and check in.

We have never discussed merging changes, and since it looks like we haven't all mastered the Check Out, Modify, Check In basics I am a little worried about going near the more complex idea of merging.

When I find out what is really happening, I'll let you know.

[jclausius]

Within Vault, when you check out a file, it can have many different statuses.

When working with the "Require Check Out before Check In" option enabled, if a user does a "GET" and starts working on the file (with the mode to use checkout before commit), the file's status will turn to "Renegade". The user cannot commit any change until the file has been checked out. Once checked out, the file's status is changed to "Editied" assuming there have been changes to the file.

Now, if the user's file falls a couple of versions behind ,the renegade status changes to "Needs Merge". Resolving a Merge status can cause problems if the end user chooses to IGNORE the merge by choosing "Resolve Merge Status." Ninety-nine percent of the time, most users SHOULD NOT CHOOSE RESOLVE MERGE STATUS. A Resolve Merge status without GETting from the server will results in changes being removed from the latest file. Instead users should do a SHOW MERGE to merge in the changes or attempt an automatic merge through GET.

Also note, you cannot commit changes to a file unless it's status is edited. A Renegade or Needs Merge file will not be sent to the server.

We will checkout what went wrong. Probably we have modifed that report in our local project and then checked out sourcevault and updated that file there before taking a Get Latest Version from Source vaut and updating our local project.

From this, it looks like the users are working renegade. When they commit, they will need to check out before the commit. If there have been other changes that do not match by default the checkout will retrieve those changes and try to merge them into the file. Also note, user's can see their changes by showing differences on any file they are about to commit to the repository. There is no indication if they are resolving merges incorrectly.

In any case, if you need other information to pass along to the users, please let me know.