This is possibly the worst piece of software I have ever...

[Mordachai]

...had to use.

What goes through your designers heads when they design "get latest" to stumble upon already-currently checked out files?

How can any source control system possibly fail to know to skip those files? Or have an option to do so (which doesn't then cause all local files to be quietly overwritten, or cause all local files to fail to be updated to latest, neither of which is the least bit useful or intelligent or helpful in any possible way).

I have the checked out - of course my copies are not to be overwritten (that operation has a name - a separate accessible function: undo check out). How abysmally simple do you have to be to think that there is a question as to how to handle this?

How can this software be so limited and yet call itself "version control software"?

I keep struggling to understand what set of modalities are intended by your designers? How do you perceive folks using your software? What are the interactions of least resistance? And what I keep finding is that even the most basic, the simplest, the most fundamental interactions between a source control system and a local file system give Vault extreme consternation. It doesn't know the first thing about how to be a source control system.

This is just ... I'm speechless.

Worst source control ever.

[Beth]

You have a couple different ways to deal with modified files on disk:

1) When you check out a file, a window will pop up with options. One of those options is "Prompt for modified files." When you check that check box, you will receive a pop-up when Vault reaches a file that is edited. You can then choose to not overwrite it or overwrite it.

2) If you want the "Prompt for modified files" to always be checked automatically, go to Vault Tools - Options - Local Files and check the options "Prompt before overwriting locally modified files."

3) When checking out you can choose one of the other options instead of "Overwrite." This will get files, but not perform any overwriting.

4) If you have already overwritten files, you can retrieve your changes back. Vault makes a backup whenever changes are overwritten. To get those back, right-click the parent folder that holds the overwritten file and select Properties. Click on Backup Files. Add all the files you wish to restore to the restore list at the bottom. Then click Restore All.

[DAWPage]

An issue I have, is when in the client, and you select a branch and do a "Get Latest" on a branch, it does not give you the warning screen, it will overwrite anything I have checked out. This has bit me in the butt a few times.


Dave Williamson

[Beth]

Mordachai: I looked back at a previous post you had relating to read-only flags and overwriting. Is that still the issue?
http://support.sourcegear.com/viewtopic.php?f=5&t=21865

If this is something different, can you tell me more about what happened?

[Beth]

DAWPage: There isn't a separate setting for branches. Try holding down your shift key when you perform a Get Latest. Does the options window pop up then? If so, then at the bottom is a check box for "Only show this dialog when the shift key is down." You would need to uncheck that to see the options all the time.

[DAWPage]

Ok, the prompt comes up now, thanks.

[Mordachai]

It's everything put together.

• No way to mark a file as "okay to overwrite with latest"
• No way to mark a file as "don't overwrite" (other side of same coin)
• Constant incorrect status (because Vault uses a local cache rather than referring to the actual database in order to determine state (incorrectly))
• No simple way to get Vault to resolve its erroneous statuses correctly (or even a non-simple way)
  • Basic issue: using the same local folders for using vault by two different users - Vault is forever confused and wrong about what state the files are in. Vault seems to store the cached status files per-user, but since this is the same place on the file system, the reality is per-machine. Vault needs to have a setting to turn its terrible status-mechanic off and use the actual database to derive all status information (correctly at all times).
  • Alternately: have a switch to make Vault store its cached data in the same location on the filesystem, so that both users end up sharing status cache data, which then would make them in-sync.
  • Alternately: be a hellovalot smarter when determining status so that when the software freaking looks at the database and finds that the local copy matches the server - THEN ERASE THE ERRONEOUS STATUS!
• Minor: incredibly slow when first accessed after reboot of server. I mean like 10+ mins slow. No mechanism to relieve this problem available.
• No feedback from Vault when it decides to overwrite a local file with something from the database.
  • Such files go into _sgbak, but no message is presented to the user (not even in the messages tab).
  • This stems from the #1 problem with vault: no way to mark files as "okay to overwrite" and "not okay to overwrite". This missing concept would eliminate most of my frustration with this product. The lack of this fundamental concept for a source management system is mind-blowing and the reason behind labeling this software "possibly the worst ever."

[Beth]

Mordachai:

No way to mark a file as "okay to overwrite with latest"
No way to mark a file as "don't overwrite" (other side of same coin)

Is using the setting "Prompt for modified files" not an option? What does that do if it's used in your case?

constant incorrect status (because Vault uses a local cache rather than referring to the actual database in order to determine state (incorrectly))

This would relate to the next point. Using the same working folder for multiple users will cause

Basic issue: using the same local folders for using vault by two different users - Vault is forever confused and wrong about what state the files are in. Vault seems to store the cached status files per-user, but since this is the same place on the file system, the reality is per-machine. Vault needs to have a setting to turn its terrible status-mechanic off and use the actual database to derive all status information (correctly at all times).

You are correct in what happens when multiple users use the same working folder. One thing you can try to see if it helps, it to turn on CRC checks. That setting is found in the Vault Tools - Options - Local Files.

I will talk to the developers about some of the options you suggested.

Minor: incredibly slow when first accessed after reboot of server.

Go to the Vault Tools - Options - Network Settings and uncheck the settings "Request database delta on repository cache miss." That should make it faster for you. Let me know if this helps.

No feedback from Vault when it decides to overwrite a local file with something from the database.

I'll put this in as a separate feature request. F: 17611

[Mordachai]

Is using the setting "Prompt for modified files" not an option? What does that do if it's used in your case?

No way to script this (would have to babysit every interaction - totally anathema to scripting).
Tedious to ascertain for each individual file yes/no.

I'll try your other suggestions and listen to hear if there is progress on any of the other issues.

However, the above is far & away the biggest hurdle for us. I would give it a weight of 19, the rest combined a weight of 1.

[Beth]

I have a few more questions to help me see if I can find a way to make this work for you.

1) Are there ever cases where a user will have two files set to writable, and both have changes, but you want one overwritten and the other not overwritten?

2) Do you ever have a file set to read-only that has changes that need to be checked in?

3) What would happen to your files if you used the option "attempt automatic merge" when performing a Get? For example, do you have any changes lost or do you end up needing some changes overwritten that aren't?

4) In what circumstances do you perform a Get? By that I mean do you only Get when others have checked in changes, or do you perform a Get every morning by habit, or do you perform a Get when you need some particular changes overwritten?

I have an idea where if we can find what consistent status the files you want overwritten have, then Gets could be performed from our Search pane.

[Mordachai]

Let's set some terms:
checked-out: a file is checked-out from vault by the current user in the working folder.
read-only: file is marked as read-only and checked in (not checked out).
rogue: file is marked as editable, but not checked out.

1) Are there ever cases where a user will have two files set to writable, and both have changes, but you want one overwritten and the other not overwritten?

checked-out: untouched by get-latest unless doing an automatic merge.
read-only: overwritten (and remains read-only).
rogue: prompt user for "overwrite?" If yes - then backup current file to _sgbak and overwrite.

2) Do you ever have a file set to read-only that has changes that need to be checked in?

checked-out: unusual scenario, but the checked-out status is what's important, so it would not be overwritten by a get-latest.
read-only: overwrite. (By its very definition, a r/o file is flagged as "overwrite at will".)
rogue: Doesn't apply in this circumstance: such a file as this should not be considered rogue (see above definitions). because this file is read-only, it is to be overwritten.

3) What would happen to your files if you used the option "attempt automatic merge" when performing a Get? For example, do you have any changes lost or do you end up needing some changes overwritten that aren't?

checked out: an auto-merge is attempted. If it succeeds, then my still-editable file contains my changes + repository changes, and it is still checked out, and awaiting me to check it in.
read-only: they're simply overwritten with the latest from the repository.
rogue: prompt the user by default (same as #1)

4) In what circumstances do you perform a Get? By that I mean do you only Get when others have checked in changes, or do you perform a Get every morning by habit, or do you perform a Get when you need some particular changes overwritten?

Typically:
A) After I check in a change-set - I've got nothing checked out - so a very excellent time to get-latest so my next set of changes start from a coherent & latest code-base.
B) After a co-worker has checked in a set of files - so that I can ensure that my changes are compatible (this would be a good auto-merge scenario for any files I have checked out that s/he also changed).

NOTE: to undo a check-out and discard changes - I would actually use the "undo checkout" to discard my changes and revert to the latest copy of that file (or perhaps to revert to what it was before I started editing it). But get-latest shouldn't have anything to do with a checked out file ever. If I have it checked out - then it should have no relationship (not be under the purview of) get-latest.

I have an idea where if we can find what consistent status the files you want overwritten have, then Gets could be performed from our Search pane.

Okay - what's your idea?

[Beth]

I decided my initial idea wouldn't work in this case. Would having a meeting to walk through few cases work for you? If so, send an email to support at sourcegear.com (attn: Beth) with a link to this forum thread, and I'll set us up from there.