Does design of Vault support seamless refactoring?

Guest · Post by **Guest** » Mon Dec 06, 2004 9:42 am

I like to refactor my code. Refactoring was difficult while using CVS, which doesn't support moving and renaming without losing history unless the moving and renaming are done administratively. I would much rather do the moving and renaming via my tools without worrying about losing history or mangling the project somehow. The file-based design of CVS was a limitation.

I switched to Subversion, and refactoring was no longer risky in relation to SCM. Subversion is directory or tree based, giving me the freedom to refactor my project at will without the headaches I encountered while using CVS.

At my new job, we're using VSS. I get the feeling that refactoring and VSS go together like refactoring and CVS. Since we're looking at other SCM systems, including Vault, I'd like to know: Is Vault file-based like VSS or CVS, or is it directory/tree based like Subversion? Will I be as free to refactor while using Vault as I was while using Subversion?

Many thanks,
Craig Demyanovich

Post by **jclausius** » Mon Dec 06, 2004 9:53 am

Moving / renaming files and folders within the Vault GUI client should not present any problems. Object histories will remain in place.

Vault tracks all File System Objects internally by an Object ID. Moving and renaming objects keeps the Object ID intact.

Please note, I'm stressing the tool Vault GUI client, as moving / renaming from within VS.Net 2003 is not supported by Microsoft's SCC API, and can knock the Vault Tree out of synch with the projects within VS.Net

Guest · Post by **Guest** » Mon Dec 06, 2004 10:02 am

Thanks for the info. To be sure I understand, let me ask about a specific scenario. If I'm using the <a href="http://www.jetbrains.com/resharper/inde ... Sharper</a> add-in for VS.NET, and I issue a rename refactoring on a file, I will "knock the Vault Tree out of synch with the projects within VS.Net?" However, if I use the Vault GUI client, all will be well?

Thanks again,
Craig[/url]

Post by **jclausius** » Mon Dec 06, 2004 10:28 am

If Resharper modifies the name of a file found within the project while VS.Net, then yes that is correct. VS.Net fails to notify Vault of the changes. In this case, you would need to rename the file within either the Vault GUI or Command Line Client.

See if this KB article ( and the related MS article ) helps - FAQ: Renaming or Deleting Files within Visual Studio.Net

ericsink · Post by **ericsink** » Mon Dec 06, 2004 10:59 am

Note that this limitation is not specific to Vault. I don't know much about Resharper, but if it uses MSSCCI, it won't work properly with ANY source control system. It's a problem with VS.NET and the way it deals with source control.

Guest · Post by **Guest** » Mon Dec 06, 2004 11:32 am

Since Vault is using the MSSCCI API, structural refactorings, ones that involve changes to the name or location of files/folders within a project structure, via a tool or one if its plugins do not work well. Like CVS, I would need to use administrative tools to accomplish such refactorings. Have I understood correctly?

I may have misunderstood the role that the file-based design of an SCM system plays in the ability to refactor. As I think back to using IDEA, an awesome Java IDE, it's refactoring tools were CVS-aware. Thus, refactoring can be done mercilessly with a file-based SCM system like CVS if the right techniques are used.

ReSharper, by the way, is simply a refactoring tool for VS.NET. It aims to (gradually) bring to the .NET world the same high quality refactoring tools that Java developers have used for years now. To the best of my knowledge, it does not interact directly with any SCM via any API.

Thank you very much to all for your help in understanding Vault.

Regards,
Craig Demyanovich

Post by **jclausius** » Mon Dec 06, 2004 1:56 pm

Craig wrote:Since Vault is using the MSSCCI API, structural refactorings, ones that involve changes to the name or location of files/folders within a project structure, via a tool or one if its plugins do not work well. Like CVS, I would need to use administrative tools to accomplish such refactorings.

That is incorrect.

Assuming you have general permissions on the folders ( or do not use folder security ), simply use the Vault GUI client to rename the folder/file, or move the object to a new location within the source tree. The Vault GUI client is not an administrative tool, but a fully featured Vault client.

Please note, you can also use the Vault Command Line client to move / rename objects as well.

Guest · Post by **Guest** » Mon Dec 06, 2004 2:38 pm

I agree that my use of the phrase "administrative tool" is incorrect. Rather, I should've stated my conclusion thus: Since Vault uses the MSSCCI API, any structural refactoring must be done using the Vault client. In other words, it must be done outside the IDE, even though I'm using a tool (ReSharper) that provides structural refactoring features.

I appreciate very much your discussing this topic with me. I'm sorry that I've used so many words to get to the heart of what matters to me. I want to be able to do refactoring without the SCM system impeding me in any way. It appears that anything using the MSSCCI API will do so, a limitation of the API, not necessarily the SCM tools using it. That SCM tools provide features to compensate for the API limitations is excellent value to their users. I would rather choose a combination of tools, though, that fit my work patterns better.

Regards,
Craig

Post by **jclausius** » Mon Dec 06, 2004 3:00 pm

Your last post clearly summarizes the current state of integration within VS.Net.

Hopefully things will improve as Microsoft improves the "hooks" for SCM tools within VS.Net.

mlippert · Post by **mlippert** » Tue Dec 07, 2004 4:59 pm

Seems to me that you should disable any source control integration in Visual Studio, and instead just use the source control manager's client such as the Vault GUI client to perform all checkin/checkout, or edit/merge/commits.

I'm fairly sure that Vault can perform the moves/renames just as well as Subversion can, and that the Subversion Visual Studio integration will have the same issues as Vault would have.

In other words the problem you've been discussing isn't due to Vault's use of the MSSCCI API, it's due to the fact that the MSSCCI API is Visual Studio's only mechanism for interacting with ANY source control system. If you don't let Visual Studio monkey with your source control then you may have an extra step, but everything should work.

I wonder if you use Vault in the edit/merge/commit mode if that might not work better for you than checkout/checkin.

Mike