Problem with pinned files which were imported

Jerry R · Post by **Jerry R** » Wed Jun 23, 2004 2:15 pm

About a month ago, we put out a release of our software and shared and pinned our source tree. This was under SourceSafe. Last weekend we migrated to Vault, and everything in our main code branch is fine. However, I just discovered that a number of folders in our release branch are not pinned inside Vault. I don't know whether this is because the SS database had errors in, because the import tool didn't work properly, or something else. That's beside the point, because we're too far along to re-import or go back to SS.

So I figure any files which are shared but not pinned in the release branch need to be pinned at the correct date. And files which have been branched do not need to be pinned. Is there a way to do this that doesn't involved going into every file in every folder which is shared and individually getting a history, pinning the file, and going on to the next?

lbauer · Post by **lbauer** » Wed Jun 23, 2004 3:40 pm

The VSS Import Tool uses the SourceSafe automation component to communicate with the VSS database. In our experience with our SourceOffSite product, we've found that the automation component can be somewhat unreliable about reporting the status of pinned files.

The only way to restore the pins is manually as you've described or by creating a script and using the Vault Client API or CLC to repin the files\folders .

If you'd like to create a script, let us know -- we can help with this.

Jerry R · Post by **Jerry R** » Thu Jun 24, 2004 8:45 am

Using the CLC, how would I determine whether given file is shared, and if so, pin it at a version with a specified label? If I knew this, I could take care of generating a file list to run it on.

Post by **jeremy_sg** » Thu Jun 24, 2004 9:00 am

In order to determine if a file is shared, use the clientinstance.treecache.IsShared() method.

To get the version of the file with a certain label, use the clientinstance.GetByLabel_GetStructure to get the label structure. Look through the structure that is returned to find the item with the correct ID. That item will have the correct version to send to the pin command.

Jerry R · Post by **Jerry R** » Thu Jun 24, 2004 9:38 am

Ok, I was hoping to avoid learning C#, but it seems like this isn't something that can be done with the command line client and C# seems like the easiest interface to use for this. I found one example on your site for doing history queries. Are there other examples I can look at as well?

By the way, the VaultRepositoryInfo object used in the example does not appear to be documented in the Vault Client API help file.

Edit: Actually, there are many items used in the history example that aren't documented in the help file: VaultConnection, VaultClientNetLib, etc. Sometimes these are referenced in the help file, but clicking on the link brings up a Page Cannot Be Displayed.

Jerry R · Post by **Jerry R** » Thu Jun 24, 2004 11:51 am

With the following code:
-----------------
string hostname, username, password, repository;

hostname = "http://surat/VaultService";
username = "jerry";
password = "";
repository = "MetaMorph";

ClientInstance myClient = new ClientInstance();
myClient.Init(VaultClientNetLib.VaultConnection.AccessLevelType.Client);
myClient.Login(hostname, username, password);
-----------------
I get this exception on the Init line:

An unhandled exception of type 'System.Configuration.ConfigurationException' occurred in system.dll

Additional information: Error loading XML file c:\windows\microsoft.net\framework\v1.0.3705\Config\machine.config Request for the permission of type System.Security.Permissions.StrongNameIdentityPermission, mscorlib, Version=1.0.3300.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 failed.

I'm able to use the command line client without any problems.

Jerry R · Post by **Jerry R** » Thu Jun 24, 2004 12:43 pm

The problem went away when I booted in my other partition and compiled the code using Visual Studio.NET 2003 (the above problem occured under Visual Studio .NET 2002). According to the exception message, 2002 seems to use the 1.0 .NET Framework even though I set the references for system.dll, etc, to the 1.1 Framework (both are installed). I'm assuming Framework mismatch between the Vault API and my program is the cause of the problem.

Is there a way to tell Studio 2002 to use the 1.1 Framework? All my main development environment is on the partition with 2002.

Post by **jclausius** » Thu Jun 24, 2004 1:14 pm

Hope no-one minds if I chime in.

From the information I've seen on the Internet, VS.Net 2002 cannot be forced to create code against the 1.1 .Net framework.

However, all is not totally lost. You could try the VS.Net 2002 .Net Patch ( http://download.sourcegear.com/files/Vault_VS2002.zip ).

You should be able to download / uncompress these libraries, and have all the necessary components to build your utility within VS.Net 2002.

A word of caution - Please keep these libraries separate from your normal Vault installation, as they have been compiled in VS.Net 2002 against the 1.0 framework and are not compatible with the normal Vault 2.0.3 release.

HTH

Jerry R · Post by **Jerry R** » Thu Jun 24, 2004 4:03 pm

Thanks Jeff - that worked. Between looking at the history example and the source for the command line client I was able to figure out what I needed as far as writing C# code to communicate with the Vault API. I know the Vault API isn't officially supported, but I hope you don't mind if I tell you the documentation needs a lot of work. There are a lot of undocumented functions, broken links, and lack of anything that tells you how to get started or how the various classes are organized. Don't get me wrong - it was helpful sometimes, and I don't want you to think I'm bashing your product. I'm far happier with Vault that SS. I can give specific examples if you're interested, but for now I'll just leave this obtuse parameter description from GetByLabel_GetStructure, which I still have no idea what it means:

labelSubItemPath
The inside-the-label path of the item (file or folder) that you want to be the root of the returned delta. Can be null, but if the ID of currentPathToLabelItem is found mlutiple times in the label, multiple paths will be returned in discoveredSubItemPaths.

Post by **jeremy_sg** » Thu Jun 24, 2004 5:31 pm

After you set up the 2002 patch (which is just regular vault compiled with the 1.1 Framework), you will need to update the references that point to program files\sourcegear to point to the 2002 patch directory.

Post by **jclausius** » Thu Jun 24, 2004 9:54 pm

Jerry R wrote:I'll just leave this obtuse parameter description from GetByLabel_GetStructure, which I still have no idea what it means:

labelSubItemPath
The inside-the-label path of the item (file or folder) that you want to be the root of the returned delta. Can be null, but if the ID of currentPathToLabelItem is found mlutiple times in the label, multiple paths will be returned in discoveredSubItemPaths.

Although I didn't write the documentation, I did write the API method, so you can blame me for its "awkwardness".

Here is the explanation - Probably 99% of the time you won't need to use the labelSubItemPath. You will normally leave this parameter null. With that said, here is why the parameter exists.

Imagine a folder label, applied on $/Projects/Proj/Src/Resources/dir, which looks like the following:

dir/
dir/A/
dir/A/share.txt (v 3, shared, pinned)
dir/B/
dir/B/share.txt (v 6, shared)

If you would ask for share.txt within this label, which one would be retrieved? Do you want to retrieve the one which was pinned at version 3 or the one at version 6?

For this example, we want the "unpinned" version. You would use the dir/B/share.txt as the label sub path to get the correct item.

Does that explain the parameter?

Jerry R wrote:I know the Vault API isn't officially supported, but I hope you don't mind if I tell you the documentation needs a lot of work. There are a lot of undocumented functions, broken links, and lack of anything that tells you how to get started or how the various classes are organized. Don't get me wrong - it was helpful sometimes, and I don't want you to think I'm bashing your product. I'm far happier with Vault that SS.

I don't mind. In fact, it is good to hear honest feedback (pro or con).

Due to time constraints this area of the system remains very, very rough. We do have it on our to-do list to make things easier in this area.

Thanks again for the feedback.

Jerry R · Post by **Jerry R** » Fri Jun 25, 2004 9:10 am

Jeff - I think I see - both share.txt's have the same ID, so when requesting by ID, it wouldn't know how to distinguish them.

As far as my comments on the product - as a software developer myself, it's such a pleasure to be using a program that is actually supported, where you can actually get feedback in a timely manner from the people who wrote it, where they're actively improving it, that it makes me want to provide you with as much feedback as possible to help you make it even better.

Vault is much better than SS, and I've been very happy with it so far. Every stumbling block I've come across has been quickly resolved with a visit to the forums here. And while I've encountered a lot of things to give feedback on, I'd say probably 90% of them are easily addressed user interface issues that aren't surprising in a product this early in its lifecycle. As a developer, I know that these types of things can be hard to be aware of, since coming at the product from the inside, you use it in certain ways, not necessarily all the unexpected ways external users are going to use it.

Anyway, this is my long winded way of saying I'm glad you're receptive to constructive comments, and perhaps I'll start making a list as I come across them, rather than nickel-and-diming you.