Question about how GET should work

dvystrcil · Post by **dvystrcil** » Fri Nov 04, 2005 10:24 am

When I use GET it appears to sync all files and not the delta that has changed. This does not seem to be the case for GETLABEL. Is this the way GET was intended to work?

dan · Post by **dan** » Fri Nov 04, 2005 10:54 am

I'm not sure I understand the issue - can you explain what you mean by not syncing the delta that has changed?

Thanks,

dvystrcil · Post by **dvystrcil** » Fri Nov 04, 2005 11:02 am

Say I have 100 files but only 2 have changes. When I use GET it syncs all 100. I was hoping that it would behave like GETLABEL and the GUI Client where it would only sync the 2 files that had changed.

dan · Post by **dan** » Fri Nov 04, 2005 11:09 am

Which client are you using?

Is the issue that it seems to be retrieving 100 files? If so, how does it indicate that?

dvystrcil · Post by **dvystrcil** » Fri Nov 04, 2005 11:22 am

Using this command line I can see that each file's modified time is getting updated. With GETLABEL and the GUI this does not happen (yes both are setting the files as read-only).

%SGVCLNT% -host %SGVHOST% -user %SGVUSER% -password "" -repository %SGVRPOS% REMEMBERLOGIN

%SGVCLNT% GET %SGVPROJ% -destpath %WORK_DIR% -verbose -makereadonly

I am seeing this with the latest client installed (v3.1.4).

dan · Post by **dan** » Fri Nov 04, 2005 2:46 pm

The -destpath parameter is what is messing it up. This indicates to Vault that it is a non-working folder that you are getting the files to, so it ignores any files that exist in the folder and simply overwrites them. If you remove -destpath, it will pick up the actual working folder and it should only get files that need to be updated.

dvystrcil · Post by **dvystrcil** » Fri Nov 04, 2005 2:50 pm

Can I place a request to have GET work like GETLABEL which has "-labelworkingfolder", so GET would have something like "-workingfolder"

PACEGMBH · Post by **PACEGMBH** » Fri Nov 04, 2005 3:26 pm

Please add my vote for this request.

Dan - I want to add some general remarks:

1. I find the different options for GET and GETLABEL confusing.

2. From just reading the documentation of the command line client it is impossible to understand the differences between the destpath and labelfolder options. Is there a real use case for the destpath option or is it rather academic?

2. The documentation as well as your post do not mention that using GET with the current working folder as well as using GETLABEl with labelworkingfolder do not work UNLESS you set the follwing setting in Tools -> Options of the Vault GUI Client:

"Store Working Folder State/Baseline Files" In Working Folder

I would suggest to address this problem or temporarily at least to document the workaround well in the documentation of the command line client.

3. For many users building complex applications the command line client is essential to get reliable scripts getting either labeled or latest versions of the app.

My 3 (Euro) cents on this issue

Frank

dan · Post by **dan** » Fri Nov 04, 2005 4:17 pm

-workingfolder would be redundant, since Get is designed to retrieve files to the working folder by default (the doc says "the files will be stored in the corresponding working folders on the local system").

Yes, I agree the destpath parameter is confusing. We use it here to build the product, because we do a fresh GET to a non-working folder for each build. Users use it for the same reason they do Gets to non-working folders in the GUI client - to retrieve files from the server without altering your working folder.

I'll log a feature to update the documentation to make it more clear that it is non-working folder being specified, and by default you should not specify anything.

The documentation as well as your post do not mention that using GET with the current working folder as well as using GETLABEl with labelworkingfolder do not work UNLESS you set the follwing setting in Tools -> Options of the Vault GUI Client:

"Store Working Folder State/Baseline Files" In Working Folder

I would suggest to address this problem or temporarily at least to document the workaround well in the documentation of the command line client.

I don't believe that this is a limitation, and just tried it out to verify., and it worked fine for me here. What kind of error do you get when you store baseline files in the cache folder?

PACEGMBH · Post by **PACEGMBH** » Fri Nov 04, 2005 5:32 pm

Hi Dan,

thank you for logging the feature update regarding the destpath option.

-workingfolder would be redundant, since Get is designed to retrieve files to the working folder by default (the doc says "the files will be stored in the corresponding working folders on the local system").

If you use GETLABEL -labelworkingfolder you get properly updated baseline data in the _sgvault folder without changing the workingfolder. That's the big difference to GET, which always works on the working folder unless you use the destpath option, which does not create baseline data. Therefore a new option GET -workingfolder would be quite helpful.

I don't believe that this is a limitation, and just tried it out to verify., and it worked fine for me here. What kind of error do you get when you store baseline files in the cache folder?

I just tried it out too: Apparently the command line client (3.1.3) respects now the setting of the GUI client. I am sure that in a previous version this did not properly work because we had some discussions on this subject at the time.

Frank

PACEGMBH · Post by **PACEGMBH** » Mon Nov 07, 2005 11:47 am

Hi Dan,

since I got no reply I wan to make sure that I properly explained to you why we really need GET -workingfolder. Was I clear enough?

Frank

dan · Post by **dan** » Mon Nov 07, 2005 1:47 pm

GETLABEL does not get files to a working folder by default, so you have to specify either -labelworkingfolder (to get the label to an existing working folder) or -destpath (to get the label to a non-working folder). By default, GET retrieves files to the defined working folder.

If you use GET and it retrieves files to the working folder, it does update the baseline files, the same as it does for GETLABEL with -labelworkingfolder specified. Both GET and GETLABEL also support -destpath, which does not update the baseline files.

So, a -workingfolder option on GET would be convenient if you wanted to set or change the working folder associated with a folder, but I'm still not seeing how it is necessary, or different from GETLABEL.

PACEGMBH · Post by **PACEGMBH** » Tue Nov 08, 2005 1:53 am

My point is that using GET w/o the -destpath option gets the files to the working folder. In case you have several builds to maintain containing the same component you will have to constantly change the working folder, which is kind of ugly:

"%SGVAULT%/vault" unsetworkingfolder "$/ThirdpartyLibraries/QuickGraph"
"%SGVAULT%/vault" setworkingfolder "$/ThirdpartyLibraries/QuickGraph" "%EWB_MainDir%/src/QuickGraph"
"%SGVAULT%/vault" get -makereadonly -merge later "$/ThirdpartyLibraries/QuickGraph"

This scenario could be improved by having a separate -workingfolder option, where you can pass the working folder for the GET w/o actually changing the currently set working folder for the component as it is required today.

dan · Post by **dan** » Tue Nov 08, 2005 8:41 am

I see - you want a -workingfolder option to temporarily act as if the working folder is the one you specify, but not permanently change it. I'll add this as a feature request.

PACEGMBH · Post by **PACEGMBH** » Tue Nov 08, 2005 11:16 am

Thanks!