Best practice on managing deletions in Vault

Igor.Samoylenko · Post by **Igor.Samoylenko** » Wed Apr 12, 2006 5:47 am

Hi,

I have a number of questions regarding the best strategy for managing deletions in Vault generally.

First a quick outline of our development environment.

We use task branches to manage concurrent development and have a separate code line to match the latest release (Trunk). Here is an outline of the structure we use:

Solution/Trunk
Solution/TaskBranches/v1.1
Solution/TaskBranches/v1.0.1
Solution/Archive/v1.0

Here: In Trunk there is source that matches the latest release; there are two active task branches (v1.1 and v1.0.1) and one old archived task branch (v1.0). Testing/releases are made from task branches. On release they are merged into Trunk and the other live task branches and archived.

We also use labelling extensively to mark various stages of development on task branches and trunks.

This structure works great for us; we have the flexibility we need at the same time maintaining a single trunk for each solution and the old versions for reference.

I have two problems managing deletions:

1. When a file needs to be deleted, it will likely to happen in a task branch. The file will be deleted and this will be later merged into Trunk on release.

The problem is with obliteration: I can obliterate the file in the task branch but it is unlikely that I will be able to obliterate the file in the Trunk (after the merge) because there are likely be archived task branches with this file in them.

This means these deleted files will accumulate and unless/until all archived task branches are deleted and obliterated I will not be able to obliterate it.

2. The other problem is more serious.

As I said earlier we use labelling extensively. The idea is obviously that it is possible to get back to a specific version at any time and whatever happens to the source files after the label is set.

It works to a point: label captures the files as they are and handles renames, moves etc properly. The problem is when the file is deleted and later obliterated, it is removed from any past labels as well. I have just discovered it today - I have been routinely obliterating deleted files to keep the number of deleted files small

.

This seems to imply that no files should ever be obliterated because it would change the labels retrospectively. This obviously means the list of deleted files will grow and will become unmanageable.

I would be grateful for any ideas on the best way to manage deletions. This should be a general problem anyone would have to deal with I would have thought?

Thanks a lot.

Regards,

Igor Samoylenko

dan · Post by **dan** » Wed Apr 12, 2006 9:17 am

There isn't much we can do about the first issue because of the design of Vault, but actually that design makes it hopefully not as big of an issue as you might think.

Vault actually stores only one copy of historical versions of a file that exist in trunks and branches. So, a file that is in both trunk and archive has only one copy of the historical versions that they share. In fact, that is why you have to obliterate branches before obliterating trunks, because you can't obliterate historical versions of file without obliterating the branched versions first.

So, the only thing taking up extra space in your DB are the versions in trunk that were created after the branch.

Note also that we have an export/import tool that will be available in a month or so with the 3.5 release of Vault. This will allow you to move your archives to new repository, and then delete and obliterate the archive branch, which would then allow you obliterate the trunk version.

For the 2nd issue, I guess I would say that yes, if you want to retain the ability to retrieve old labels, you should never use obliterate. In fact, that is the difference between delete and obliterate - you can still retrieve deleted files, but obliterated files are gone forever.

Igor.Samoylenko · Post by **Igor.Samoylenko** » Wed Apr 12, 2006 9:58 am

Thanks Dan. This export facility will definitely help with the first issue.

As for the second one - I must admit I was a bit surprised to see that obliteration removes the labelled versions of the file as well. I assumed that it will leave the labelled versions of the file; to delete which you would have to go to "view label" and delete from there (or something like that).

I don't particularly mind leaving the deleted files and not obliterating them but in this case the managment of obliterations will need to be seriously improved to prevent becoming unmanageable. There has been a lot of suggestions as to how it can be done. Using trees etc will definitely help - so please add my vote towards all of those features already requested!

Actually, what changes relating to obliteration are planned for the forthcoming release(s)?

Regards,

Igor.

dan · Post by **dan** » Wed Apr 12, 2006 10:06 am

Labels are just tags on files and folders, so the file itself is "primary" in this relationship. Without the file, there is no label for the file, so that is the design issue.

Yes, our obliterate mechansim needs serious work. It won't be ready for 3.5, but we plan to redesign it for 4.0, tentatively due out near the end of this year. So, hopefully help will eventually be on the way