Revert to old version - available in 3.1?

[pandaurae]

I have inherited a development team using Vault 2.0.3 and am in the processing of coordinating an obvious upgrade to 3.1. I also have the enviable task of restructing the code to something more intelligent.

It is my desire to begin branched development of the numerous "features" requested by the business and have a question regarding discussions I have been perusing regarding rollback:

In Vault 3.1, is the feature available to allow me to select the version of a folder that existed before a branch merge and rollback its contents to that previous version? If a developer has merged their branch into the trunk and severely broken the build, I would love to simply rollback to the version previous to the merge.

In the current version we are using, 2.0.3, this is near-to-impossible. I am hoping this is has been implemented in the current Vault version ... could someone please enlighten me?

Thanks!

[lbauer]

Folder rollback is not yet available for Vault; it's logged as a feature for 4.0, our next release.

If you want to go back to a version before the merge, there are some workarounds.

You could Show History->View Folder History by Version, select the version prior to the merge and Get that version, then checkin those files. Or you could Branch that version and work in the new branch.

[pandaurae]

I have been attempting to do just that with this current version as a workaround and, no matter what I do, after I "Get" the version I want, Vault will not see those files as "modified", so will not check them in.

I am hoping this is corrected in the latest version and, if so, I am happy enough to use that workaround for our purposes.

The technique I have tried in 2.0.3 without success is:
1. Check out the entire folder
2. Get History on that folder, selecting the version previous to the merge
3. Get that previous version, overwriting the local files I have checked out
4. Check in that overwrite -- it is here that the process fails. Vault does not see them as modified, so the "overwritten" changes do not get checked in (more like "undo checkout").

So, if this is at least fixed in 3.1, I will be content until 4.0 is released.

Thanks!!

(I will test the "branching from the previous version" option in this version until my complaining proves fruitful in getting the business to upgrade. Thanks for that tip!)

[lbauer]

So, if this is at least fixed in 3.1, I will be content until 4.0 is released.

Actually, the workaround would be to do a get to a non-working folder, checkout the folder(s) in the tree, then replace the contents of the working folders with the Get. Vault would now see these files as edited, rather than Old, etc. You'd have to do additional tweaking to add or delete files as necessary.

The label branch is probably a better idea.

[pandaurae]

Thank you so much for that insight! It never occured to me to Get the previous version to a non-working folder and replace the current version after check-out ... duh!

This method is my preference for how I want to handle branching. The main Trunk code will always be the "current buildable version" and I will maintain it as such. I will provide the development team a branch for each major feature to be added so they can work independently. When they are done, the merge will be attempted and this option, I feel, works the best for us if that merge seriously breaks the build and we need to back that out.

I can see the complete history of the branch merge and when that merge was backed-out. Just what I wanted ... thank you again!

[lbauer]

Eric Sink has some useful how-to's for branching in his blog; you might want to see these links:

http://www.ericsink.com/scm/scm_branches.html

http://www.ericsink.com/scm/scm_merge_branches.html