GETLABEL will not get files recursively, only folders (V2.0)
Moderator: SourceGear
There is no way in the current release to Get by label on a folder if the label doesn't exist at that folder, and labels are always recursive.
So, the best we could do is to label the folder, and then remove items that don't apply. Users could then add the files back to the label if they wanted to.
Since we provide the source code to our command line client, you could try to implement the "Get recursive file label of the same name" functionality. It might be extremely slow though, depending on the size of your tree.
I can't really promise that this will be in a release in the immediate future, but we will add it to the feature request list.
So, the best we could do is to label the folder, and then remove items that don't apply. Users could then add the files back to the label if they wanted to.
Since we provide the source code to our command line client, you could try to implement the "Get recursive file label of the same name" functionality. It might be extremely slow though, depending on the size of your tree.
I can't really promise that this will be in a release in the immediate future, but we will add it to the feature request list.
Can you please give a simple description of how to set up and run the command line client source code? I have been able to compile it OK, but I always get an error in the following location:
void Logout(bool bForceLogout)
{
if ( (_ci != null) &&
((bForceLogout == true) || (_args.InBatchMode == false))
)
{
// log out when forced or not in batch mode.
_ci.Logout();
_ci = null; // <-- Error happens here
}
}
Here is the stack trace of the error:
Unhandled Exception: System.NullReferenceException: Object reference not set to an instance of an object.
at VaultClientNetLib.VaultConnection.Logout()
at VaultClientOperationsLib.ClientInstance.Logout()
at VaultCmdLineClient.VaultCmdLineClient.Logout(Boolean bForceLogout) in d:\source\hydra\system\other\vaultcmdline\v01\windowsapp\vaultcmdlineclient\vaultcmdlineclient.cs:line 437 at VaultCmdLineClient.VaultCmdLineClient.Main(String[] args) in d:\source\hydra\system\other\vaultcmdline\v01\windowsapp\vaultcmdlineclient\vaultcmdlineclient.cs:line 3830
void Logout(bool bForceLogout)
{
if ( (_ci != null) &&
((bForceLogout == true) || (_args.InBatchMode == false))
)
{
// log out when forced or not in batch mode.
_ci.Logout();
_ci = null; // <-- Error happens here
}
}
Here is the stack trace of the error:
Unhandled Exception: System.NullReferenceException: Object reference not set to an instance of an object.
at VaultClientNetLib.VaultConnection.Logout()
at VaultClientOperationsLib.ClientInstance.Logout()
at VaultCmdLineClient.VaultCmdLineClient.Logout(Boolean bForceLogout) in d:\source\hydra\system\other\vaultcmdline\v01\windowsapp\vaultcmdlineclient\vaultcmdlineclient.cs:line 437 at VaultCmdLineClient.VaultCmdLineClient.Main(String[] args) in d:\source\hydra\system\other\vaultcmdline\v01\windowsapp\vaultcmdlineclient\vaultcmdlineclient.cs:line 3830
Hm... logout should be unaffected by working folder configuration, though. If the stacktrace is correct, and the exception really comes from VaultConnection.Logout, the error may be related to the connection's _clientService member getting set to null somewhere. I can't find any functions in VaultConnection that set _clientService to null, except Init, which is supposed to.
Shaw Terwilliger
SourceGear LLC
`echo sterwill5sourcegear6com | tr 56 @.`
SourceGear LLC
`echo sterwill5sourcegear6com | tr 56 @.`
It's possible that the DLLs that contain the implementation of ClientInstance and VaultConnection don't work correctly when called from code compiled with Visual Studio .NET 2002, although I think .NET assemblies are designed to be able to do this. Releases of Vault 2.0 are compiled with Visual Studio .NET 2003.
Shaw Terwilliger
SourceGear LLC
`echo sterwill5sourcegear6com | tr 56 @.`
SourceGear LLC
`echo sterwill5sourcegear6com | tr 56 @.`
Thanks Dan - we implemented your suggestion, and it's working! For a tree 5000+ files, it took the client around 5 minutes to locate the couple that we'd labelled.dan wrote:Since we provide the source code to our command line client, you could try to implement the "Get recursive file label of the same name" functionality. It might be extremely slow though, depending on the size of your tree.
This is very comparable with the time taken by SourceSafe to do the same thing. We implemented it as a really simple-minded O(n) "schlemiel the painter" algorithm, but even with that is matches VSS in speed.
Speaking of which - any comments from the Sourcegear developers on a better way of doing this? Here's what we're doing:
- call _ci.TreeCache.Repository.Root.FindFolderRecursive() to access the folder we're "getting" at.
- call GetFilesRecursive() to get the files under that folder.
- iterate (foreach) file in the collection
- call GetLabeledFileToNonWorkingFolder() for that file, passing in the label we want.
Files that don't have a matching label throw an exception, which we catch and ignore.
Files that match are "got".
Any comments?
This is the last piece we needed...now at last we have the authority to purchase Vault licenses for all our developers.
FWIW, we do the same thing. Whilst I have not yet attempted to fetch everything by a label, this thread might lead me to believe that I will be unsuccessful in my attempts because of the way I label files (one-by-one).jclausius wrote: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"?
That's correct - if you label a single file at a time, you have to get by individual file too. If you want to get an entire folder with a label name, you need to apply the label to the folder.montek wrote: FWIW, we do the same thing. Whilst I have not yet attempted to fetch everything by a label, this thread might lead me to believe that I will be unsuccessful in my attempts because of the way I label files (one-by-one).
Well that's not useful at all. I can't label an entire folder because I can only deploy SOME versions of SOME files in it...hence the labeling.dan wrote:That's correct - if you label a single file at a time, you have to get by individual file too. If you want to get an entire folder with a label name, you need to apply the label to the folder.montek wrote: FWIW, we do the same thing. Whilst I have not yet attempted to fetch everything by a label, this thread might lead me to believe that I will be unsuccessful in my attempts because of the way I label files (one-by-one).
This might work great if I were working on a non-web project where you solidify the whole thing before you release, but that just doesn't represent our environment at all.