|
#1
|
|||
|
|||
VBP/Surround SCM problem
When performing a "get" from Surround SCM with VBP, the following command line is used:
sscm.exe get /* -dD:\root\dir1\dir2 -zSERVER:4900 -yuser:pass "-pMAINLINE/Repository1/Repository2" -bBRANCH -r -e -f -tmodify -wreplace Is there a way to remove the "-d" from the front of the directory? I couldn't find a way to get rid of it anywhere in the Surround menu. When using the "-d" option, Surround assumes that you are getting the files to a directory other than the working directory. What happens is the .MySCMServerInfo file is not updated when using the "-d" command. This causes incorrect file versions and file status when working in the GUI app. The file status will say "old" or "modified", when they should say current. The files are identical, but this can be very confusing and caused a whole lot of stress for one of my co-workers. |
#2
|
|||
|
|||
Clear out the 'Directory for local files' field to remove the -d flag (this will remove -d and the directory; according to the Surround SCM CLI Guide, the path by itself would not be valid anyway).
|
#3
|
|||
|
|||
That is incorrect, the information I wrote below I received from Seapine tech support. The support agent had taken the issue to development and about a week later I recieved an email stating that the -d option bypasses the .MYSCMServerInfo file. The workaround is to specify the directory without the -d option. I have tried doing a get this way from a command prompt and it works.
|
#4
|
|||
|
|||
Interesting. Which version is this change implemented in (it's not documented in v4.1 ref guide)? Which location(s) in the command-line can this argument be placed? Multiple item specs are allowed, so I'm not sure how it can reliably determine if the last one is a directory vs. another item spec (sounds like a backward compatibility issue). If it can immediately follow the items, you can move the path value from the 'Directory for local files' field to the end (on its own line) in the 'Items and/or files to process' field.
|
#5
|
|||
|
|||
I did some more investigating and found out why *I think* VBP calls the "-d" option. In order for you to not use the "-d" option you have to have a working directory set. You have to set a working directory through either the GUI or CLI. I like not having to set a working directory, however. This makes it easier for me when building on different machines. It would not be so fun to have to set working directories for each machine and user, especially when certain repositories do not inheret the working directory from the parent.
When the working directory is set, you do not specify a directory at all in the command line. It would look like this: sscm.exe get /* -zSERVER:4900 -yuser:pass "-pMAINLINE/Repository1/Repository2" -bBRANCH -r -e -f -tmodify -wreplace So I guess there are advantages to either way. It wouldn't be to hard to work around this using a "Run Program" step in the build script with a command line similar to the one above. |
#6
|
|||
|
|||
So your former statement about passing the path on the command-line without -d doesn't apply?
By working directory, do you mean a) calling the workdir command within Surround, or b) setting the working directory of the sscm process that is invoked? Is there any documentation on the specific differences (i.e., handling of .MySCMServerInfo, etc.) for working dir vs -d and when to prefer either or both? If you meant a), you should be able to use another step to first set the working dir. If you meant b), you could add a Set Current Dir action before the Surround SCM action to set the current dir for later Surround SCM steps to use. |
#7
|
|||
|
|||
Correct. I thought not using the "-d" option had worked, but I was wrong. The working directory is a local folder to which a repository in Surround is assigned. The workdir command is used to set a working directory. I was thinking about this a little more last night. This is the resolution that I came up with:
1) Open up the GUI and setup all working directories or use the CLI command "workdir" to setup all working directories 2) When using the Surround SCM step where in VBP, do not enter anything for a directory. This will fix the whole problem I originally wrote in about, the reason I did not having working directories setup is that the login I use for Surround is different than the login the build machine uses. The build machine login never has had working directories set. If you setup your working folders before using VBP and do not enter anything in the "directory for local files" field, Surround will assume that you want to work in your working directory and automatically work out of that folder. This will also allow Surround to add all necessary information to the .MYSCMServerinfofile. I still prefer using the "-d" option, but others may not. |
|
|