SourceGear Support

Posted: **Tue Nov 16, 2010 3:51 pm**

Hello

I have a problem with the get command using the API.

Here is the code I use...

ServerOperations.client.LoginOptions.URL = url;
ServerOperations.client.LoginOptions.User = username;
ServerOperations.client.LoginOptions.Password = password;
ServerOperations.client.LoginOptions.Repository = repository;
ServerOperations.client.AutoCommit = true;
ServerOperations.Login();

getOptions = new GetOptions();
getOptions.Recursive = true;
getOptions.SetFileTime = SetFileTimeType.Current;
getOptions.Merge = MergeType.OverwriteWorkingCopy;
            
GetOperations.ProcessCommandGet(new String[]{"$/Something/Something"}, getOptions);

Everything works fine and i do get the files downloaded in the right folder. However, all the files are "renegate" if I look through the Vault Client.

Any ideas why that would happen to me?

Thanks a lot

Posted: **Tue Nov 16, 2010 4:44 pm**

If files are touched or updated when the file is not checked out, it will receive a status of renegade. Your options are to either check out the files first or to work in CVS mode. CVS mode is set in the Vault Tools - Options - Concurrent Development Style.

Posted: **Wed Nov 17, 2010 9:04 am**

Thanks for responding,

Maybe I wasn't very clear on what my problem was I will try to explain a little bit better. I use Vault 4.1.4 btw

I am trying to do a get latest version on a folder $/Something/Something and there is 4 different ways i can do it.

1 - Log in the Vault Client application and get the folder.

2- Execute a command line operation using the Vault Client application vault.exe. Here is the command I use :
C:\Program Files\SourceGear\Vault Client>vault.exe GET -repository Test -user admin -password admin -host 127.0.0.1 $/Something/Something

3- Execute a command line operation using the JavaCLC vault.cmd. Here is the command I use :
C:\Documents and Settings\fringuette\My Documents\Downloads\vaultJavaCLC>vault.cmd GET -repository Test -user admin -password admin -host 127.0.0.1 $/Something/Something

4- Run the code in my previous post.

I assumed the result would be the same for the 4 ways but it isn't.

When I run the option 1 or 2, my result is perfect. The files are downloaded and if I look in the vault client after, all files are at the right version without any status which is what I expect to happen.

When I run the option 3 or 4, my result isn't what I expect. The files are downloaded in the proper folder. But if i open the Vault Client application, the files have the right version number but are marked as renegade even if I haven't changed anything in they in the meantime. Also, if I do a file compare on the file downloaded and the "right" version from vault, they are shown as being identical but yet they remain renegade.

Hope you can help me out because I am trying to devellop a tool and would like to use option 4.

Thanks

Posted: **Wed Nov 17, 2010 4:32 pm**

Is your API using a different user than what you use in Vault or the command-line client?

For the Java CLC, you want to just use vault not vaultcmd.

Posted: **Wed Nov 17, 2010 6:05 pm**

No I am using the same user.

I've tryed the same code in C# instead of Java and it's working as expected. I guess I will write my tool in C# instead.

Thanks anyway

Posted: **Thu Nov 18, 2010 11:42 am**

Thank you for the update.

Posted: **Wed Feb 23, 2011 9:50 am**

Hi again,

I know it has been a long time since i posted the original issue but i was just able yesterday to update my vault server from 4.1.4 to 5.1.1 and test this issue again.

Basically what I did is download the Java CLC app and unzipped it in c:\vaultclient

Now I open 2 command prompt...one to the folder c:\vaultclient and one to the folder C:\Program Files\SourceGear\Vault Client.

Then I open my vault client 5.1.1 and browse to the repository Repo to the folder $/Something/Something. I right click and do a explore working folder and delete everything in there.

Now from the c:\vaultclient command promt, I do the following command vault.cmd GET -repository Repo -user admin -password password -host 127.0.0.1 $/Something/Something

Once the operation is done, I look in my vault client and all files in $/Something/Something are renegate.

Now a delete all files again in the folder and from the C:\Program Files\SourceGear\Vault Client command promt i run the following vault.exe GET -repository Repo -user admin -password password -host 127.0.0.1 $/Something/Something.

Once the operation is done, I look in my vault client and all files are not renegate.

I would expect the Java CLC not to make all files renegate and I think this is a bug...or maybe my server has some wierd configuration.

Any chance you could test this somewhere and see if you get the same result or have a way to get around this issue?

Thanks

Posted: **Wed Feb 23, 2011 5:01 pm**

I'm running some tests to see what's going on.

What happens if you select your Vault GUI client and click F5? Does the status change?

Posted: **Thu Feb 24, 2011 10:55 am**

The status doesn't change. I've tried it every time I ran that test.

Posted: **Mon Feb 28, 2011 10:42 am**

any update on this issue?

Posted: **Mon Feb 28, 2011 2:53 pm**

I've reproduced the issue, but I haven't found a way yet around it. I'm still researching the issue.

Posted: **Mon Feb 28, 2011 3:38 pm**

I had a discussion with the developers about this and it appears that the Java CLC and the Vault GUI client look in different places for cache information. Without the cache update, it looks like some outside program made the changes to the working folder. You should have also noticed that the Java CLC does not inherit the working folder from the Vault GUI client.

If you are on a Windows machine, you can also use the Vault CLC and that uses the same cache location as the GUI client. The Vault CLC is automatically installed when you install the Vault GUI client. You would just go to the same location as the Vault client with the command line and run the same commands.

Posted: **Tue Mar 01, 2011 12:56 pm**

Thank you for your answer.

Any way I can make the Java CLC look in the same place as the Vault GUI?

The goal of all this is to be able to use the Java CLC within my application and not as command line. Reporting the issue as a command line issue was just easier as it's basically the same command on both the Java CLC and vault CLC. I know i can use the Vault CSC and that is actually what we are using right now but I wan't to change that and use the Java classes of your API directly. Since my application is already all in Java I don't really want to migrate to C# where I know the API works fine.

Thanks

Posted: **Thu Mar 03, 2011 5:29 pm**

Any work-around wouldn't be supported nor guaranteed to work.

I've been trying a few things out with this and currently my Vault GUI client is able to resolve the renegade status after I check in from the Java CLC. Is that the case for you as well?

Do you only use the Java CLC for a Get or do you perform other actions with it?

Posted: **Fri Mar 04, 2011 9:27 am**

I use pretty much all commands from the Java CLC.

Here is the sequence i've tried.

- GET from Java CLC -> Files are shown as renegate
- CHECKOUT from Java CLC -> Files are shown as edited in the top right panel, and Size unchanged, Modified in the pending change set tab
- manually modify one of the files previously checkouted -> Only the modified file shows a -17kb status the rest stays the same
- CHECKIN from the Java CLC -> The manually modified file is shown without a status which is good, all other file are still renegate since they were rollbacked with an undo checkout by the Java CLC

Thanks for the effort you're putting into this I appreciate it

SourceGear Support

Problem with GetOperations.ProcessCommandGet

Problem with GetOperations.ProcessCommandGet

Re: Problem with GetOperations.ProcessCommandGet

Re: Problem with GetOperations.ProcessCommandGet

Re: Problem with GetOperations.ProcessCommandGet

Re: Problem with GetOperations.ProcessCommandGet

Re: Problem with GetOperations.ProcessCommandGet

Re: Problem with GetOperations.ProcessCommandGet

Re: Problem with GetOperations.ProcessCommandGet

Re: Problem with GetOperations.ProcessCommandGet

Re: Problem with GetOperations.ProcessCommandGet

Re: Problem with GetOperations.ProcessCommandGet

Re: Problem with GetOperations.ProcessCommandGet

Re: Problem with GetOperations.ProcessCommandGet

Re: Problem with GetOperations.ProcessCommandGet

Re: Problem with GetOperations.ProcessCommandGet