GETLABEL will not get files recursively, only folders (V2.0)

jeremymc · Post by **jeremymc** » Sat Feb 21, 2004 12:47 am

I have been trying to get this to work for hours now. I have applied a label called V01.0020 to a specific folder in my tree. When I show history on any file below that folder, I can clearly see that the label is there. However, when I use the GETLABEL command line syntax, it will only recursively build the folder structure on my local drive. None of the files under that label will show up on disk. The command line syntax I am using is:

C:\Program Files\SourceGear\Vault Client\vault.exe getlabel -host vault.hrbl.net -user jeremymc -password fake -repository
Future -merge overwrite -destfolder C:\Test $/System/Internet/MyHerbalife/VIPCentral/V01 V01.0020

Can anyone think of a reason why the files themselves would not be coming down? I am totally stumped.

Guest · Post by **Guest** » Sat Feb 21, 2004 9:14 am

The CLC options look correct to me.

Try getting the same label from the GUI client to the same non-working folder and see if you get the same results. They use the same underlying libraries so it should fail in the same way, if you are logged in as the same user on the same machine. There might be error messages in the GUI client that don't get output in the CLC?

jeremymc · Post by **jeremymc** » Sun Feb 22, 2004 9:42 am

The same thing happens when using the GUI, and there is no error message. I get latest of the label recursively, but only the folders show up. The files are not there.

Note: From the "Show Labels" grid, if I select "View..." on the particular label, and then the "View Label Structure" window pops up, I see the entire thing with all the files and everything. So, it looks like everything is definitely labeled correctly. There just seems to be a problem with the GETLABELS command.

jeremymc · Post by **jeremymc** » Sun Feb 22, 2004 9:53 am

One other detail...

If I drill down to an individual file, and then right click "Show Labels", I can see the label right there (as an inherited label). When I right click and select "Get..." on the label, then select C:\Temp as the local destination directory, the file doesn't show up (as usual). The message shown in the GUI is:

[2/22/2004 7:43:40 AM] Getting latest version of 5714e4ca-8f6f-4377-9029-8fefa1f5e621/AssemblyInfo.vb
[2/22/2004 7:43:40 AM] Finished get latest of 5714e4ca-8f6f-4377-9029-8fefa1f5e621/AssemblyInfo.vb

I have attached a screenshot of the Show Labels window.

Post by **jeremy_sg** » Sun Feb 22, 2004 11:42 am

The presence of the GUID tips this off as a bug. What version of Vault are you using? We fixed a bug like this partway through the 2.0 cycle, but you might be seeing another manifestation of it. As a workaround, try setting the <TreeCompressionThreshold> in your vault.config to some very big number to disable tree compression. You'll have to reset IIS in order to reload the setting. How many items are in this label?

I'll look into this.

Guest · Post by **Guest** » Sun Feb 22, 2004 3:51 pm

The version is 2.0.0 (2120) (taken from the About Vault Admin Tool...).

I set the <TreeDeltaCompresionThreshold> to 10,000,000 (vs. 1000), and I restarted IIS, but it did not have any effect. I still see the GUID's, and the file does not appear.

One other detail which might help: When I right click on the inherited file label abd try to View it, I get the error in the attached screenshot.

Guest · Post by **Guest** » Sun Feb 22, 2004 3:55 pm

Sorry, one more detail:

The database was upgraded from version 1.2.3. However, the label was applied after the upgrade.

Post by **jeremy_sg** » Sun Feb 22, 2004 10:02 pm

Jeremy,

Send me an email with your phone number, and we'll investigate this offline.

sterwill · Post by **sterwill** » Mon Feb 23, 2004 8:52 am

Actually, the GUID thing is normal for label gets. We can't share working folders between labeled tree folders and normal tree folders, so we have to use temporary (GUID-named) working folders for label gets.

DarrenS · Post by **DarrenS** » Tue Feb 24, 2004 2:57 pm

Colleague of JeremyMc's chiming in here.

Regarding the issue of getting empty folders when using 'vault getlabel': we did a clean install of Vault on a "virgin" machine, and lo and behold, 'getlabel' is behaving as it should: when we 'getlabel' on (say) label V1.0, we end up with the correct folder structure and all the source files within them.

We can only conclude that it was the upgrade to Vault 2.0 that broke the "getlabel" functionality, since it works fine on a clean install.

However, we now have another major issue. Well, it's major for us because we are trying to persuade our company to make the switch, and VSS currently has this functionality.

What we would like to do is this: when you do a "getlabel" on a particular folder, we'd like a way to have Vault search all files within that folder and subfolders of it, and get any source files with that label, even if the folder itself doesn't have that label.

For example,

Code: Select all

Project1       <--- not labelled
     File1.vb   <--- was labelled Ver2.3
     File2.vb   <--- not labelled
     Project2
         File3.vb  <--- labelled Ver2.3
         File4.vb  <--- not labelled

When we do a "getlabel" for label 'Ver2.3' on Project1, we'd like to have the folder structure recreated as it is in Vault, but with only the files File1.vb and File3.vb retrieved. As I mentioned, this is how it works in VSS and our whole build process centers around it.

Is there an existing way of accomplishing this in Vault? It really is a make-or-break feature for us.

jeremymc · Post by **jeremymc** » Tue Feb 24, 2004 3:50 pm

As a result of Darren's research, I uninstalled and then reinstalled the Vault 2.0 server which was experiencing this problem, and guess what? It now works fine. Hooray! (I guess there's something wrong with the upgrade process.)

However, as Darren mentioned above, we really need the ability to recursively get files which have a specific label, where the parent folder acted upon does not have that label. (Darren described it better than me.) This would allow us to sell the product to a separate development team in our company and would help upper management buy into the product whole-heartedly.

dan · Post by **dan** » Tue Feb 24, 2004 4:31 pm

Bummer - that isn't a feature we currently support.

We do support label promotion, where you can change the version number of a file associated with the label, or remove a file from label entirely. But, this would require you to label a folder, and then remove the files you don't want from it, which probably isn't what you want.

If you provide more information on why you need that feature, we might be able to figure out if Vault can accomplish the same goal in another way...

Post by **jclausius** » Tue Feb 24, 2004 5:21 pm

jeremy / darren:

just want to make sure i understand you. are you saying you individually label each and every file?

in other words... in the example you provided, would you go to file1.vb and apply a label named "Ver2.3", and then go to file3.vb and apply a label named "Ver2.3"?

jeremymc · Post by **jeremymc** » Tue Feb 24, 2004 5:41 pm

Yes, exactly. The other core development team in our company (named Phoenix), handles their build and deployment process in a different way from us (we label folders in their entirety).

Basically, when a bug or feature request is logged, it has a specific ticket number associated with it. The developers are told by the build master that when they fix this bug, they must label the files that they have touched with this specific ticket #. Then, the build master does a build and deployment for specific bugs or feature requests by only getting latest on files labeled with specific ticket numbers.

It's kinda quirky, but it's how they do it. VSS is able to do this. Basically, it looks like you guys could allow this pretty easily if you were able to merge the capabilities of the GETLABEL and GETWILDCARD command line options. (like if GETWILDCARD could accept a label as an optional parameter.)

Guest · Post by **Guest** » Wed Feb 25, 2004 12:26 pm

Any workaround for this or suggestions from the Vault team? This really could be a showstopper for our adoption of Vault. The other bugs and issues we can deal with, but due to our rather quirky build process, this is a must-have. Please don't condemn us to another 5 years of VSS!

Would this be something you guys could provide by "scripting" a couple of the existing web services?