check in new folder & items bug

[Perry]

I have Vault Options/Check In/Auto-Commit after each operation unchecked.

I Create Folder to add a new folder, lets say "data", in the Vault tree.

Then I copy a folder named data with many files into the working location on my hard drive.

Then I go into Vault, click on the parent folder (where "data" will appear), and push the Add Files toolbar button. I select the "data" folder (as I have to, to get the subitems to show up), and this selects all the new files for me.

Then I try to commit what I have, and I get an error.

As near as I can tell, the pending create for "data" is in conflict with the pending add for "data" and its subfolders.

So, I don't know how this is supposed to work, but I'm guessing that now I need to right-click undo one of these items in my Pending Change Set.

[Perry]

Vault version 3.0.6 (2856)

(That number in the Help/About is sadly not copyable)

[lbauer]

You probably need to create the folder in one operation or change set and then add the files in another operation. So undo the add files, commit the create folder, then add the files.

[Perry]

I muddled my way out of broken change set by deleting one of the items.

However, I think the problem is that the Add Files tree allows me to try add a new folder which is already pending for creation in the existing Change Set -- by doing that (and actually, I think it requires me to do that to add the files), it causes me to enter this broken state.

[lbauer]

Since users have different ways of working, Vault doesn't regulate what's put into the pending change set. Users may add conflicting items in the change set and decide later which they actually want to commit.

If you try to commit conflicting items (like 2 of the same datafolder) Vault will catch that.

[mlippert]

What would be nice however, is if you could order the operations in the changeset, so that you could Add a folder and Add files to that folder in the same changeset, which should work if the add folder operation happens before the add files operations.

This might also facilitate renaming a file, and then modifying the renamed file, which are another set of operations I've wanted to exist in the same changeset.

I realize this isn't a simple feature, but it would be nice at some point.

Mike

[Guest]

As far as I can tell, what exists now is entirely broken.

I just hit this bug again.

I deleted a bunch of files out of a bunch of folders -- they're being replaced with ones with slightly different names. Deleting all those files in all those folders was very tedious, as Vault doesn't appear to have a recursive delete for files.

Then, I went onto the disk, and deleted all the local files in all those folders -- also tedious.

Then, I copied all the new versions into place, in all those folders. Also tedious.

Then, I went into Vault, and went to the root of the area, selected Add Files, and clicked on all the folders which have new files. Great, this part wasn't tedious, it was easy.

Then I tried to commit, and it failed.

I think the last step -- the only one not tedious -- is the problem.

I think Vault is insisting it be allowed to add all those folders, that already exist.

This sounds like the same bug as this thread -- Vault is insisting it add a bunch of folders that already exist, or it won't let me add files. Therefore, it is insisting it create a broken changeset.


As far as I can tell, the workaround is not to use the convenient multiselect in Vault, but to instead drill down through every folder and file, and check every one of the new files manually -- this is much worse than all the preceding steps, because here I have to check every individual file!

[Perry]

I can see the attractive workaround - delete all the folders (in Vault)s, then copy the new ones, then let Vault create all the new folders.

That will avoid all this horrid tediousness of doing every folder and file.

But, it will make a somewhat nonsensical change history, as the change history will show deleting and recreating a bunch of folders, which is hard to explain, as the only reason for it is to work around this bug in Vault I think

[Perry]

This is sad.

I found that I can deselect the folder that already exists in Vault (to avoid Vault creating a broken changeset), and select all the files under it by using ctrl-A and checking any one of them. That avoids the nightmare of checking each file in each folder manually.

*BUT*, then it intends to add every file to the root, not to the folder under which it belongs.

Its kind of funny, it almost lets me avoid checking every file, except it won't put them in the right place if I don't go thru and check every file.

I think I'll surrender now, and delete all the folders and start over.

[dan]

If you already have the folders created in Vault, try the "Detect New Files to Add" option, which will search the working folder for files that are not in the repository and put them in the right place in the tree.

[Perry]

Now that workaround (use Detect files, and stay away from Add files) worked like a charm -- I just added a whole directory full of directories, and did not have to go through the tediousness of doing each one, one directory at a time!

Thanks.