Pin not commited

[Xavier]

Hello

unless I'm wrong Pin/unpin do not require commit. Is there something wrong in my setup or is it by design ?
A fix would be great, as generally we pin .h & .cpp at the same time, so committing both changes at the same time makes sense.

Thanks

Xavier

[lbauer]

Pin and unpin do not require a commit, as they do not make a change to the file or folder history. When you pin a version of a file, that version becomes the current version, and no changes can be made until the file is unpinned.

A fix would be great, as generally we pin .h & .cpp at the same time, so committing both changes at the same time makes sense

I could use more details about how you would like Pin to be different. Would you like multiple files to be pinned at the same time?

[Xavier]

Yes, I would like to pin several files at the same time.

I'm rather disappointed that pin/unpin are not in history. According to me this is mandatory.... You cannot have an history that is correct if you do not store this information. However this explains why it do not require a commit.

It doesn't modify the file history, but according to me it's bug if it doesn't change the folder history.... It means you wouldn't be able to get a label exactly as soon as you unpin a file

[lbauer]

Sorry, I was mistaken about Pin in history. The action does show up in the history of the parent, but not in the file history. So, hopefully, you're not quite as disappointed.

You can pin several files at a time from the file list, but that's probably not what you have in mind.

Could you describe how you would like this feature to work, so if we do implement it, we will have the right solution?

[Xavier]

In one sentence: I would like to have the pin/unpin command be present in the commit list.

Otherwise... Let's take an example (a real one as you can guess).

I work on project A that is to be released in a while and make important changes on a shared class (.cpp & .h)
Someone works on project B that was to be released this evening; he was happy because he made sure everything was OK, but meanwhile my check-in break its code; and even if it doesn't break the code, is risky.

Then, it's almost impossible to make a branch (of the whole project B), because I've made the check in before him. Moreover, there might be some other changes before we decide to make a branch of project B and unpin the files. So the simplest solution is to pin .h & .cpp to the former version (in our case it was several version before in fact). The I cannot use the file list, I have to select history of .h, Pin, history of .cpp, Pin. Then the pins are not in the same folder revision.

So I think that Pin to version X, Unpin should appear in the Pending Changes just like all other operations (move, delete, ....)

I hope it's clear. I'm not sure the example was required; the problem is that it breaks the idea of atomic versions... (it required 4 pins in my case).

[lbauer]

If you turn off automatic commits while you are working on your pinning, the Pins (And Unpins) will sit in the pending change set until committed.
The setting is in the Vault GUI client under Tools-> Options-> Concurrent Development Environment.

[Xavier]

Then, at last, I understand...

It only fails from the history window.

It's not commited if done from the file list, you have it in the pending change set
It's automatically commited (whatever option you have selected) if you select a file, show history, then pin any version.

[Xavier]

BTW, Pin/Unpin from the history window also bypass the 'comment required for check-in' option if set in the server

[lbauer]

Hm. That's right.

I've logged feature request 15232 for this functionality.

Thanks for your comments.

[Xavier]

I would suggest that you log those as a bugs
- Pin/Unpin from the history window also bypass the 'comment required for check-in' option if set in the server, is a bug, though not critical
- Pin not sent to pending list is bug, that is according a major failure, though not critical

I honestly don't really mind for the first one, but the second does matter for us

Thanks

[lbauer]

Thanks; I've added your comments to the work item.