Former VSS user, confused by differences

[Mordachai]

In VSS, I would mark a file as read-only in order to indicate that VSS should overwrite my local copy with the updated (or retrograde) copy from source safe.

I would mark a file as writable to indicate I was working on that file, and it should not be updated by a get-latest. Essentially, if I had it checked out, then it was checked out & being edited. If I didn't have it checked out, then it was renegade, but required manual intervention to sync it with source control.

In Vault, I'm endlessly confused by vault's client which tells me that read-only files are either "renegade" or "needs merge" when clearly, they are neither renegade nor in need of a merge. They are simply out of date - but since they're read-only, they're free to be overwritten by the next get-latest from vault.

But the vault client refuses to actually do a get-latest on those files. I have to manually override it and force it to overwrite those files by hand.

This sucks a ton - it causes my scripts to fail, it causes problems on the production machine where Vault refuses to update files that need to be updated.

Is there some setting in Vault to tell it "if the file is read-only, then it is ready to be sync'd up with source control"?

Alternately, is there another approach I should be taking with Vault that would avoid this whole mess in the first place? I really need Vault and myself (and my scripts) to all agree on the basic concept of "this file is or is not in a state which can be overwritten at anytime from source control (and should be)". VSS used read-only as the flag for this, what is the equivalent in vault???

[Beth]

In Vault, if you want to have the file read-only normally, and then edit the file, you would check out the file first, then perform the edits. Then your status and cache files will be correct.

If you don't want to use the check-out function, then rather than changing the read-only flag, you should move to using the CVS mode, which sets all files to writable. Then you can edit them at any time and Vault will just mark them as edited.

The modes of working are set in the Vault Tools - Options - Concurrent Development Style.

[Mordachai]

That's not right.

I don't want to edit them all of the time, and I definitely don't want them to be writable!

I want them to be writable if and only if I've got them checked out.

When they're not checked out, they should be read only (so that all other software knows that it shouldn't change the files).

I just want Vault to correctly update them when they're no longer in sync with vault - which it refuses to do - regardless of their being read only or writable.

if the files were writable, I could understand Vault's reluctance to overwrite them - they're probably intentionally edited locally.

But when they're read-only, I really wish Vault would overwrite them with updates in source control. If they're read-only - any changes in them are forfeit / illegal / irrelevant / discardable.

[Beth]

Before editing a file, are you checking out the file?

[Mordachai]

That depends.

If I want the edits to be considered non-temporary - valid changes - then yes, I check them out first.

If I want the edits to be considered purely throw-away temporary - then no, I don't check them out - I just edit them and force their state to read-only (using scripts) so that they'll be overwritten by the source control version the next time a get-latest is done (discarding the temporary changes).

---

If there is another way to effect the same results, please let me know.

---

A similar complication occurs on the server, where the working folder is shared amongst two accounts: Build-master and Translation-master. The common working folder is used for generating builds. But Vault is forever complaining that files are rogue or needs merge because they were checked out, edited, and checked in using one account, but the other account is now confused (even though the file is correct - and in sync with Vault - it still thinks it's wrong).

[GregM]

Are you doing the get latest immediately after running the script that is marking the file as read-only? If so, then you can just delete the file, and the get will replace it.

[Mordachai]

Unfortunately, no. The scripts (or my temporary manual edits) set up some conditions that are needed to perform additional tasks that extend beyond the script or immediate moment. They're no longer needed at exactly the moment I do a get-latest (that's equivalent to - throw away temp stuff, make sure I'm synched up with the server now, please)

[Beth]

When you are performing a Get through Vault, are you using the Attempt Automatic Merge option or the Overwrite option?

[Mordachai]

Hi Beth - sorry for the long delay...

We're not communicating, it would seem.

I have a script - named "Get Latest language files & checksum them for retail build.bat"

When that runs, it does:

1. a VAULT GET on a bunch of files (which generally succeeds). Those files are now read-only, and up to date. (Yay).
2. It then changes their attributes to writable
3. and runs an internal tool named "Checksum.exe" which modifies each of those files to have a line on the end which is a checksum computation (we use this to detect tampering of our retail builds).
4. It then changes their attributes back to read-only again.

So now I can run my development environment in release build, which requires that the language files have these up-to-date checksums in them.

When I am finished doing whatever testing or debugging was required, I am ready to undo my renegade changes to those language files.

THIS IS WHERE I HAVE A PROBLEM.

If I run my vault client, it tells me that those files are either "RENEGADE" or "NEEDS MERGE". Okay, sure, that's true that they're renegade.

What I WANT is a way to run VAULT and say "If the file is read-only, then it is okay to overwrite it with the copy from source-control, always, without asking me, forever and ever and ever."

But instead, if I ask vault to "get latest", then it stupidly fails to update any of those files.

I have my options set to "attempt merge."

But - the crucial thing here - is that it doesn't matter what my default options are here. The fact that the files are read-only should - by definition - mean that they can be overwritten by Vault without warning, without default options being considered at all. Just overwrite the files please (because they're read-only, meaning that they're not writable - they're not in edit mode - they're not checked out - they are fully available to be updated).

I'm not sure how to make this more clear.

READ-ONLY = PLEASE OVERWRITE
WRITABLE = DO NOT OVERWRITE

That's how VSS worked, and my scripts are built to take advantage of that, and I need the equivalent in Vault.

Or some alternate way of:

????? === PLEASE OVERWRITE
????? === do NOT overwrite

Feel free to tell me what ?????? stands for in the case of Vault....

[Beth]

Vault doesn't have an automatic option to decide whether to overwrite or not based on whether the file is read-only or not.

One idea though would be to include a line in your script to check the read-only flag on your file. Then you would have it run a Get with the Overwrite option if the flag is set to read-only, and Get with Automatic Merge if the file is set to writable.

[Mordachai]

Hmmm... that might be doable.

What are the chances that Vault would eventually have such a feature?

How is it that other users don't constantly run into Vault refusing to update a file because it considers it "renegade" or "needs merge", I wonder?

I can't seem to avoid those conditions constantly (probably because I make local changes that I don't intend to check in). But I'm shocked that more users out there don't also employ this pattern. Seems like a really common one.

Maybe everyone just always checks out their files, and then undoes the check out later?

[Beth]

Is using the Overwrite option instead of Needs Merge not an option?

Are there other files that can't be overwritten?

What about adding a second Get to your script that does a Get with overwrite when the checksums need to be overwritten?

Do all files get the checksum or just particular files?

[Mordachai]

I chose not to use overwrite as a default as a safety-measure. But perhaps it's not necessary. After all, if I have it checked out, then overwrite won't overwrite it? <- This would be critical. If that is the case, then I could probably just change default to overwrite.

It is just certain files for the checksum, but then there are other scripts and other techniques that do other things, and leave me in this same situation. So perhaps 'overwrite' is the better choice - IFF overwrite still doesn't overwrite checked out files?

Nope, it tries to overwrite edited, checked-out files too.

So there isn't any way to say "If I didn't check it out, then always overwrite it"

What are the chances, in real-world terms, of this ever being a feature? As it currently stands, there is absolutely no way that you are suggesting, or that I can imagine, for Vault ever to be smarter than a lump of coal. VSS was far brighter in real-world scriptable terms with its simple "read-only or not" mechanism. And the irony is, Vault could be smarter by looking at "checked out or not", but there isn't any setting or concept in the Vault pantheon for anything this basic and fundamentally useful.

[Beth]

Vault has an option to determine whether to use overwrite or not based on whether the file was modified. Not by the read-only/writable status. I can enter a feature request for the functionality you want.

You know which files get the checksum, right? If so, then you could have a Get with overwrite on just those particular files.

If there is something common in the name for the files that get the checksum added, you could also use the GetWildCard command.

[Mordachai]

I just used the checksum scenario as a concrete example, to help make it more understandable.

There are many scenarios, all of which should boil down to:

If I have it checked out, leave it alone
if not, overwrite (roll-back/update) it from source control

There is a similar issue in another guise with having multiple log-in identities share the same vault-local-folder (which happens on our severs), and still others that have to do with something as trivial as toggling read-only or other file-attributes locally.

Suffice it to say that there are many uses for the above logic. The mechanism matters little, but I would very much like the above added as a feature request.

Thank you