How to capture output from the command-line client

This forum is now locked, since Gold Support is no longer offered.

Moderator: SourceGear

Locked
Niklas
Posts: 18
Joined: Tue Mar 30, 2004 9:09 am

How to capture output from the command-line client

Post by Niklas » Thu Jan 20, 2005 8:25 am

Hi,
How do you capture information from the command-line client (vault.exe) on which local files that have been updated from repository at a ‘get’ command? How do you capture information on which local files that were not updated due to they were writeable?
Our objective is to warn the user in case any local file is writeable but not checked out.

We are migrating from VSS to Vault 3.0. We have been using a batch file to access the VSS repository from the command-line client (ss). The main purpose of this batch file is to retrieve latest files from repository, unless local files are checked out or writeable. The batch file is part of a set of scripts that provides means for each developer to update working folders and rebuild source code every night. We are now trying to convert the batch file to access a Vault repository.

A. VSS example:
Set working folder and current project. Retrieve read-only copies of all the files in the current project, and all its subprojects. Redirect all command output to ‘log.txt’.

Code: Select all

ss workfold $/Bin c:\bin -olog.txt
ss cp $/Bin -olog.txt
ss get * -r -olog.txt
if errorlevel 1 echo WARNING: Some files were not retrieved from VSS.
The VSS command-line client outputs information of each file being processed by the ‘get’ command. Output example:

Code: Select all

$/Bin
file1.c
Replacing local copy of file2.c
A writable copy of file3.c already exists
a) file1.c - Local file is up-to-date with repository.
b) Replacing local copy of file2.c - Local file needs to be updated.
c) A writable copy of file3.c already exists - Local file is writable, but not checked out.

In case a local file was not updated from repository, this can be captured with ‘if errorlevel 1’ to provide means of warning the user that some files were not retrieved. Redirection of output to a file gives a simple but powerful way of listing which files that were retrieved and which files were not.

B. Vault example:

Code: Select all

set cmGetOptions=-makereadonly -merge later -setfiletime checkin
set cmRepositoryFolder=$/Bin/
set cmLocalFolder=c:\bin
vault setworkingfolder %cmRepositoryFolder% %cmLocalFolder%
vault get %cmRepositoryFolder% %cmGetOptions%
vault unsetworkingfolder %cmRepositoryFolder%
The output from the Vault command-line client for the above example is

Code: Select all

<vault>
<listworkingfolders>
 <workingfolder reposfolder="$/Bin" localfolder="c:\bin" />
</listworkingfolders>
<result success="yes" />
</vault>
<vault>
<result success="yes" />
</vault>
<vault>
<listworkingfolders />
<result success="yes" />
</vault>
How do you get information out of Vault to find out which local files that were updated from repository and which ones that were left? Based on the current Vault batch file we have no means of indicating non-updated files as a warning to the user.
/Niklas

dan
Posts: 2448
Joined: Wed Dec 17, 2003 5:03 pm
Location: SourceGear
Contact:

Post by dan » Thu Jan 20, 2005 2:19 pm

Sorry - the command line client doesn't currently output each file as it gets it. I'll add this as a feature request. In the meantime, you'd have to modify the CLC to get the behavior you want.

Niklas
Posts: 18
Joined: Tue Mar 30, 2004 9:09 am

Post by Niklas » Wed Jan 26, 2005 2:00 am

dan wrote:Sorry - the command line client doesn't currently output each file as it gets it. I'll add this as a feature request. In the meantime, you'd have to modify the CLC to get the behavior you want.
Hi Dan,
I hope you add alot of votes for this. We tried to modify the CLC and stumbled in to this, in

Code: Select all

bool ProcessCommandGet(...)
gresponses = _ci.GetToNonWorkingFolder(...
gresponses = _ci.Get(....
We want to get the status of what vault has done. When we call the 2 different functions above. We get different behaviour.
GetToNonWorkingFolder: Gives complete file list, but the status is not different if vault actually downloaded the file or if it already was the same.
Get: Doesn't give a list of files at all.
/Niklas

Niklas
Posts: 18
Joined: Tue Mar 30, 2004 9:09 am

What we really need!

Post by Niklas » Wed Jan 26, 2005 3:45 am

Code: Select all

<member name="T:VaultClientOperationsLib.MergeType">
  <summary>An enum listing the possible choices for the Merge option</summary> 
  </member>
- <member name="F:VaultClientOperationsLib.MergeType.OverwriteWorkingCopy">
  <summary>Overwrite the working copy</summary> 
  </member>
- <member name="F:VaultClientOperationsLib.MergeType.MergeLater">
  <summary>Do nothing (merge later)</summary> 
  </member>
- <member name="F:VaultClientOperationsLib.MergeType.AttemptAutomaticMerge">
  <summary>Attempt to automatically mnerge the files</summary> 
  </member>
- <member name="F:VaultClientOperationsLib.MergeType.Unspecified">
  <summary>Unspecified</summary> 
  </member>
After investigating this further, we have found that what we need is a new mergetype.
MergeType.DoNotOverwriteWritableFiles

The intention is to download all files that are newer in the vault database, except files that are writable on the local disk (checked out or just writable)

/Niklas

christian
Posts: 202
Joined: Tue Sep 14, 2004 1:02 pm
Location: UK

Re: What we really need!

Post by christian » Wed Jan 26, 2005 5:11 am

Niklas wrote:
The intention is to download all files that are newer in the vault database, except files that are writable on the local disk (checked out or just writable)

/Niklas
Hi Niklas,
I've asked for something similar - A Get (with overwrite) that ignores those files the developer has checked out. Your requirement differs in that you want to ignore all writeable files (checked out or just writable).

My post is here: http://support.sourcegear.com/viewtopic ... highlight=

Like you, I would really like to see a greater level of control over what gets overwritten on a recursive Get.

Christian

dan
Posts: 2448
Joined: Wed Dec 17, 2003 5:03 pm
Location: SourceGear
Contact:

Post by dan » Wed Jan 26, 2005 9:15 am

I've added Niklas's vote for the requested "Don't overwrite checked out files" option.

Niklas, I'll take a look at those APIs and get back to you...

christian
Posts: 202
Joined: Tue Sep 14, 2004 1:02 pm
Location: UK

Post by christian » Wed Jan 26, 2005 9:17 am

Thanks Dan. How many votes/points does a feature need before you consider it ;-)

dan
Posts: 2448
Joined: Wed Dec 17, 2003 5:03 pm
Location: SourceGear
Contact:

Post by dan » Wed Jan 26, 2005 10:04 am

Niklas wrote:

Code: Select all

bool ProcessCommandGet(...)
gresponses = _ci.GetToNonWorkingFolder(...
gresponses = _ci.Get(....
It looks like the way the APIs work is that they return the list of files that were written to the local folder, so if no files were retrieved, they would not return anything. Whether a file is written depends partly on the MergeType option.

It is true that MergeType ignores the writability or checked out status of a file, but remember that it does take into account what is probably most important - whether the file is actually modified locally or not. So, if you tell it to "Merge Later", it will not overwrite the locally modified file.

Hope this helps at least a little...

Niklas
Posts: 18
Joined: Tue Mar 30, 2004 9:09 am

Post by Niklas » Fri Jan 28, 2005 4:06 am

Thanks Dan,

It was possible to update the CLC with our wanted behaviour. We still whish you have enough votes to implement the 'do not overwrite checked out files' mergetype, since we really need this also for the Vault Client. It has happened several times already, that developers has lost a days work since they didn't want to check in before getting and forgot the difference between vault and VSS.

We have added 2 functions to the CLC that we needed
EXGET - work's like GET, doesn't overwrite checked out files or writable files.
EXSTATUS - to check if a file is checked out by the user.

/Niklas

dan
Posts: 2448
Joined: Wed Dec 17, 2003 5:03 pm
Location: SourceGear
Contact:

Post by dan » Fri Jan 28, 2005 8:32 am

Niklas,

One workaround for this is to use the search pane and do a Get on all renegade files and overwrite them, then do a Get on all edited files and do an automerge on them. (This is assuming you require checkouts before checkins).

Locked