Obliterate Fails for No Good Reason

[davenovak]

I've often seen obliterate fail because it depends on a branch that was deleted but not obliterated. In those cases, Vault shows you the branch that is causing obliterate to fail.

But, if you look at the attached image, sometimes there is no reason.

Here are my steps to repeat:

• 1. Create Root Folder (call it TestFolder)
  2. On your local machine, create local TestFolder and add new sub-folder to this called Admin.
  3. Next, add a bunch of Files & subfolders to Admin. Use Add Files/Folders to import this into Vault.
  4. After importing, branch Admin into Admin 2.
  5. Delete Admin.
  6. Branch Admin 2 into Admin 3.
  7. Branch Admin 3 into Admin.
  7. Delete TestFolder.
  8. Using Admin Tool, try to obliterate TestFolder. You should get the error dialog below.

So, why can't I obliterate TestFolder? It has no external dependencies. This is frustrating and smells like a bug.

[Beth]

As it currently is, Vault appears to be looking at all the files that obliterate would affect, but is not differentiating between just files that are only affected internal to that folder versus outside that folder. If you had branched outside that folder, then you are affecting pieces of the database that would stay. It appears to be looking at the Admin folder possibly. I can log this for the developers to look into.

From here, what you would have to do is undo your deletes and trace back getting rid of the deletes. Then delete and obliterate your branches and then delete and obliterate your main folder.

[davenovak]

My "solution" was to undelete the TestFolder and then start deleting/obliterating the items contained therein one-by-one. Doing that showed me the deletion order I needed to follow. What a pain.

Please note that no files in this scenario were ever shared or branched outside of the root TestFolder. I understand that there needs to be a certain order of deletion/obliteration when branches are involved, but when you're deleting the root node (which contained all such branches), Vault should allow that obliteration.

I think your developers should look at this further.

[davenovak]

Question: so is this behavior by design (i.e., a "feature")? Are there any plans to fix this to be more user-friendly? I've been bitten by this now several times.

[Beth]

I guess I don't understand why you want to go about it in that fashion. Does your development model call for making lots of branches in one folder and then deleting all the work done? (Sorry, I don't know how else to phrase what it looked like to me.)

We always continually improve our product and go through all suggestions, so I'm not ignoring your dilemma, but I think I need a better understanding of why in this case. How do you wish to use branches? I think knowing that would help immensely.

Also, I think for some changes we may have to make a complete new copy of all the files and history, which could make for a very, very large database for some of our users. Right now, the previous history is referenced instead of copied, so if one gets rid of the previous history by obliterating the original, then there's nothing for the branch to reference.

[davenovak]

In some of the work that I do, I end up building temporary, independent branches. (I have scripts to automate the creation of these branches. We use these for various testing scenarios.) When I'm done with my work and testing on those temporary branches, I want to obliterate them. But obliteration always fails because I have done branching within the temporary branch (as demonstrated in my original example).

Please keep in mind that these temporary branches I am building are all independent branches. There are no ties whatsoever to other branches. Therefore, there is no good reason that obliteration should fail.

Yes, perhaps not many people set up temporary branches for testing (or whatever), but I guarantee you that others will have this problem and wonder “why?”. Pretty much all it takes is a new source root, some files and folders under that root, some branching within the root, and you will not be able to easily obliterate that folder.

As a software designer and architect, I take difference to your statement that "we may have to make a complete new copy of all the files and history, which could make for a very, very large database for some of our users." While this may be the case for branches that span roots, my conversation in this thread has always been in the context of independent roots. I'm only asking that this work this way for the case that I describe -- where all branch dependencies are contained within the root that is being deleted. As is, it's a major pain for me to obliterate and my database is growing very large because of it.

I think the current behavior should be declared a bug and a fix should be forthcoming.

[Beth]

I'll add your comments to the request that's been logged and the developers will review it. Again, thanks for the feed back.