Delete Local Copy *always* does in Vault 4.1?

[sbohlen]

Under Vault 4.1 there appears to be a new feature that is conceptually quite nice around the deleting of files (local and repos) that seems different from the way it worked in Vault 4.0.x and earlier.

To see this in action, perform the following steps...

1) have a file (say test.txt) in a folder both in the repository and in your related working folder

2) set Vault Client NOT to auto-commit (i.e., set Vault to queue actions like delete, move, etc. as pending changes instead of automatically committing them)

3) right-click on test.txt in the repository folder and select to delete the file

4) note that the delete is queued as a pending change (as expected) but that unlike in prior versions of Vault, the test.txt file is no longer displayed in the folder in the repository and is also actually no longer in the working folder on the user's hard drive either (it is removed from 'visibility' to the user in the repository and actually removed from the hard drive in the case of the working folder copy).

This pre-delete-commit change in the test.txt file BEFORE the pending delete is committed seems to be the new behavior. Interestingly (and cleverly!) any other Vault user (on another computer) can actually still see the test.txt file in the repository since the pending delete hasn't been committed by the first user yet; its just 'hidden' from the first user that queued the delete action on it.

Here comes the gotcha tho....

When this first user goes to commit the pending delete of test.txt, the dialog box offers the choice of 'delete local copy' for the user to check or uncheck as desired. However, since the local copy has actually ALREADY been removed from the working folder (see 4 above) its actually TOO LATE to indicate that you want the test.txt file to remain in your local working folder!!! (oops!)

Given this new behavior, it seems impossible any longer to perform a delete of a file that is both in the repository and in the local working folder and still leave the local working copy intact as was possible in pre-4.1 versions of Vault.

Can you please confirm that this behavior is 'as-intended' or if there is some setting that I am missing that controls this functionality (and could return it to the way it worked in pre-4.1 Vault)?

I think this may be a user-scenario that wasn't fully considered when this new 'feature' was added to Vault 4.1....

Thanks in advance,

-Steve B.

[GregM]

This was actually added to 4.0. It's not new in 4.1. I'm pretty sure I've seen some people asking for this behavior to be optional. This was, I think, added in response to the requests that people had to make delete/ rename, effect the working folder and repository view immediately, so that you can be sure that what you're going to check in actually works without having to go do the delete/rename manually yourself.

[sbohlen]

Thanks, this clears it up (sort of).

For the record, I actually find the feature to be really cool (helpful) but it plays not at all nicely with the 'delete local copy' choice (and intent) in the commit-pending-deletes dialog box.

If this feature is to be non-optional as currently implemented, then we need a way in the ensuing dialog to check a box that says 'retain local copy' during the delete operation and have Vault return the file back to the working folder as requested).

As implemented now, the checkbox is provided ('delete local copy') but the checkbox has no effect on any deletes as presently implemented -- either checked or not, Vault always deletes the local copy.

Even if this is 'by design' and there is no opt-out choice, at a minimum the checkbox should be removed since it clearly doesn't do anything at all right now and leads the user to thing Vault is 'broken' in some manner.

This feature and the 'delete local copy' checkbox are in direct functional opposition to each other...this should be cleared up ASAP somehow (make this behavior opt-in or opt-out, remove the checkbox, or something).

-Steve B.

[GregM]

FYI, I'm just a user, I don't work for SourceGear.

[sbohlen]

Yup, I got that; my reply re: what really needs to be done to address this was more targeted at an (eventual) SourceGear employee who (hopefully) will read this thread.

I appreciate the point, tho.

Thanks again,

-Steve B.

[ian_sg]

Thanks for the feedback, Steve. As usual, Greg's right on the money. This is an intentional change that first shipped with 4.0, partially in response to the many people who requested it.

We're aware that not everybody likes this behavior, and it's likely we'll make it optional in a future release.

Note that "Remove Local Copy" in the commit dialog isn't unique to deletes. Selecting that option removes local files for anything your checking in. Try selecting it when you're checking in a modification. So while perhaps unintuitive, it's not really broken or utterly misleading, I think.

Still, when we revisit this functionality in terms of making it optional, we should consider the relevance of this checkbox. I've added a reference to this thread on the bug.

[sbohlen]

Ian:

Thanks for the upd (and excellent point about the checkbox's proper role in other ops; I hadn't considered that one all the way thru!).

Again, for the record: I actually LIKE the feature, I just wish there was a way (as in past versions) to keep the local copy of something thats being deleted from the repos. This most often happens for our devs if they indiscrimiately add something to the repos then think better of it and delete it from the repos...now the result is the file is completely gone from their systems and that's obviously no good

Some way to accomodate both needs would be great as I can see the need for both behaviors in different contexts.

Thanks again,

-Steve B.

[GregM]

I think the file is placed in the _sgbak directory, as long as you haven't disabled that.

[Mike Szanto]

Okay guys, the change to this behavior is absolutely ridiculous and has caused me endless consternation since it was implemented.

Not only that, it is such a significant change that it should have been implemented in a different way. The default behaviour should have been maintained and a checkbox to enable the new behavior should have been added to the applications's options and its default setting should have been set to use the original behavior.

As it stands now, if I want to remove a file from Vault but keep its local copy, there is no way to do this without first making a local backup then restoring the backup after committing the change in Vault. Its absolutely ridiculous that I have to go through this machination just to maintain the local copy.


mike

[ian_sg]

You're right. We took too long to realize that this was too drastic a change to the default behavior. The good news is that we did finally get it.

The next maintenance release, 4.1.2, works almost exactly as you describe. There's a checkbox to turn this behavior on, but the default will be off.

Furthermore, the automatic backups (when this option is turned on) are a little more sane:

• If a file was modified before it was deleted, a backup is put in _sgbak (which is in your working folder, not the sometimes-hard-to-find cache location) and stays there indefinitely.
• The temporary files in the cache folder that allow you to undo a pended delete are cleaned up when the delete has been committed.

EDIT: One other thing I neglected to mention: you'll also be able to decide if you want to delete local files on a case-by-case basis. The delete confirmation dialog has a Delete local file(s) checkbox which defaults to the option's setting.

[jeremy_sg]

4.1.2 was just released, and has a fix for this.