Feature request: Vendor / Third party code branches

[christian]

I'm sure there are a fair few of us maintaining third party code in Vault.

Taking updates to tp code is painful whenever there have been additions, deletions and renames to the tp files. Researching this it appears that Subversion has a rather elegant solution to this pain in the form of Vendor branches and a sophisticated command that allows you to update the Vendor branch while resolving file renames.

It would be incredibly useful if a similar thing could be implemented in Vault in the form of a wizard. Is this something you can implement?

Thanks
Christian

[mlippert]

Hmm. I can't imagine any automated method to identify the cases where a file is renamed since it looks identical to deleting the original file and adding the renamed file as a new file. Obviously when you can identify this circumstance you want to commit it to Vault as a rename and not as a delete and an add.

Here are the steps I've been using to update Vault with changes made somewhere else (ie there have been no changes made to what is in Vault, so the new files do not need to be merged with what is in Vault).

This is using Vault 3.0

0) Set Vault to not require a Checkout before a Checkin.

1) Put the new version's files into a brand new directory tree.

2) Start the Vault Client and set its working directory to that new directory.

3) Using the Vault Client Search for all files that have a status of "Missing". These files have either been deleted or moved/renamed. Determine which and get the appropriate pending action into the change set.

4) Do a recursive Get Latest Version from the Vault Client into the new directory tree. Set it to not merge changed files.

5) Use the context menu item "Detect New Files to Add" on the Vault top level folder.

6) Commit All. For all files that need merge, do a "Resolve Merge Status", which says that the file in the directory is the correct new file.

Hope this is useful,
Mike

[ericsink]

Is this something you can implement?

Not without a really solid understanding of exactly how you would want it to work. Feel free to be specific and detailed. The odds of a feature go way up when we have a clear spec.

[dm_unseen]

Maybe something like a non-delta branch?

If you can specify if a branch of a project is
a: a delta branch(current vault behaviour)
b: a full file branch(always add full file, no increments/delta's)
c: a single file branch(only maintain latest file, maybe keep history of older files, but not the actual files)

b or c could be a good solution to a 3rd party vendor code branch.

[christian]

Feel free to be specific and detailed. The odds of a feature go way up when we have a clear spec. :-)

Ok, in my own words, here goes at trying to adapt and summarise the Subversion help in this area...

The Third party code is added to a seperate Vault project whose subprojects match exactly how the TP code is installed to your hard drive.
Everytime you receive an update from the TP (Subversion likes to call this a Vendor drop) you run a Vault wizard that compares the Vault project containing the previous TP release against the latest TP code as it installs itself to your hard drive.

If there are discrepancies in the file layouts between what’s in Vault and the latest TP code, the wizard will prompt you for how you would like to resolve those differences. For example, you will have the opportunity to tell the wizard that you know that the file math.c in Vault was renamed to arithmetic.c in the latest release from the TP. Any discrepancies not explained by moves are treated by the wizard as regular additions and deletions.

This is very similar to what Mike is doing but a wizard bundles the steps up into an easy to use dialog.

The original subject line "Feature request: Vendor / Third party code branches" is perhaps somewhat missleading as my explanation above makes no reference to branches! In fact the branch bit comes from what you actually do with the TP project. You branch the TP project into the Vault project containing your project code. You do this 1) to identify which version of the TP code goes with which version of your project and 2) in order to seperate out changes you make to the TP code to this branch.

Point two (2) makes it vital that renames to TP files are resolved (rather than reflected in Vault as a Delete then Add). When you want to merge the latest TP code with the files you've modified on the branch the merge will need to know the files that have been renamed in order to perform the merge without losing the changes you've made.

For perhaps a better explanation I attach a link to the Subversion help on Vendor branches... http://svnbook.red-bean.com/en/1.1/svn- ... h-7-sect-4

Eric, what with my ramblings and Mike's post this should give you enough detail :-)

Christian

[christian]

Hi Mike,
Yeah, very helpful thank you. It appears you're doing the same steps the Subversion command and Vault wizard I'm asking for wraps up into a convenient bundle.
Christian

[christian]

Any progress on this one guys?
Thanks
Christian

[mlippert]

I just thought I'd add a comment about the procedure I've been using (as outlined above).

It works pretty well except for shared files within the hierarchy. I have to track down all of the shared files and make sure that there isI only one of them in my ChangeSet. This can be a real pain.

[ericsink]

Progress? I suppose that's what you mean by the word "progress"...

Your explanation of the feature you want makes sense now. It's not a bad idea feature at all. I think of it as a bit of special help for a very specific use case. Sorry for not acknowledging this explicitly with a response to this thread.

However, I can't make any promises about implementation of this feature. We'll consider it for the next release.

Thanks!

[christian]

Ok Eric, thanks for the reply and I hope this is something you can add in the next release (or two).

Chirstian