How can I remove a specific file from a sandbox?

[jerazo]

I'm working on scripts for our team that will help automate creating sandbox with MANY files. In some cases, I'm required to not include files from specific directories. So I'd like to know if I'm creating a sandbox, how do I remove a file from the Sandbox, so that it doesn't show up on the local directory, and also if possible also not seen in the client. I'm also looking for a solution that doesn't involve limiting the whole configuration of a sandbox, but instead only in a specific sub sandbox.

[mrump]

Depending on the version of integrity you use there is a feature called "sandbox scope".

It allows you to define a "filter" for the files that are part of you sandbox. Eg. by file-extention, file-Name or  path.

The scope for a sandbox can either be set during sandbox creation or be changed for an already given sandbox.

Unfortunately the Client Gui has some limitations regarding filter Definition, so I#d recomment to use the CLI.

You should have a good look at your CLI Manual for the Details on the "si configuresandbox" command.

HTH Matthias

[jerazo]

Unfortunately, the configuresandbox command is not what I need as it works only for top level sandboxes. As I might need to filter out for example all files with names that start with "electronic" in a specific directory, but not necessarily in the whole sandbox.

[tdalon · Accepted solution]

This is partly true. You can use configuresandbox with a path option to limit the filter to a dedicated subpart of it.

To achieve your purpose you will need to combine a filter on path AND a filter on file name.

As Matthias said: have a look at the CLI documentation:

type:text|binary|memberrevlabellike:expression|anyrevlabellike:expression|any]

defines what project members are included in the Sandbox, transferring specific members from the Integrity Server to the Sandbox

directory when the Sandbox is created and controlling what members display in the Sandbox view. Changes to the scope definition are

automatically reflected in the Sandbox view. Members that no longer match the scope definition display deltas, but remain in the

Sandbox. Each member indicates that a working file exists and the member does not match the Sandbox scope. Performing a si

resync or si revert removes the members from the Sandbox. For a more detailed overview of scoped Sandboxes, see the si

createsandbox command. You can include or invert ! one or more of the following options:

--scope=attribute:name[=value] specifies project members with an attribute or an attribute set to a value. For example, include

members with --scope=attribute:Beta or do not include members with --scope=!attribute:OS=Windows. This option is

case-sensitive.

51 of 265

--scope=path:expression specifies project members that reside in a directory, relative to the top-level Sandbox, for example,

watch/lib/*. The specified path does not differentiate between subdirectories and subproject names. This means that you cannot

specify individual co-located subprojects.

For example, if you create a scoped Sandbox from the following top-level project:

/p1/project.pj

with the following subprojects and members:

//pp11//ssuubb11//apar.ojtexctt.pj //pp11//ssuubb11//bdbd..ttxxtt //pp11//ssuubb22//psrubo1j/eccct..ptjxt

specifying --scope=path:sub1 matches /p1/sub1/aa.txt and /p1/sub1/dd.txt or specifying --scope=path:*sub1

matches /p1/sub1/aa.txt, /p1/sub1/bb.txt, /p1/sub2/sub1/cc.txt, and /p1/sub1/dd.txt.

Note: If the client OS is a case-sensitive file system and the database repository on the server is case-sensitive, the --

scope=path:expression and --scope=name:expression options are case-sensitive. Otherwise, these options are case-insensitive.

--scope=name:expression specifies project members with a name or file extension. A name is only valid for a file name, not a leading

directory prefix. For example, include members with --scope=name:Readme.txt or do not include members with --

scope=!name:*.java.

--scope=memberrevlabellike:expression specifies project members with a label at member revision. For example, include

members with --scope=memberrevlabellike:TEST or do not include members with --scope=!memberrevlabellike:TEST.

This option is case-sensitive and accepts wildcards (* and ?)

--scope=anyrevlabellike:expression specifies project members with a label at any revision. For example, include members with

--scope=anyrevlabellike:PROD or do not include members with --scope=!anyrevlabellike:PROD. This option is casesensitive

and accepts wildcards (* and ?)

--scope=type:binary|text specifies project members that are a binary or text archive type. For example, include members with -

-scope=type:binary or do not include members with --scope=!type:text.

--scope=any specifies all project members. This is the default setting.

Using Logical Operators to Define Sandbox Scope

You can also combine Sandbox scope selections using logical AND or OR operators, and invert Sandbox scope selections by preceding

each selection with a ! character. An AND operator is specified as a --scope option. For example, to transfer project members with the

member attributes Alpha AND Beta, specify --scope=attribute:Alpha --scope=attribute:Beta. An OR operator is specified

as a comma between values in a --scope option. For example, to transfer project members with member attributes Alpha OR Beta

OR GA, specify --scope=attribute:Alpha,attribute:Beta,attribute:GA. You can combine logical operators to create more

complex Sandbox scope selctions. For example, to transfer project members with member attributes Alpha OR Beta OR GA AND name

*.java, specify --scope=attribute:Alpha,attribute:Beta,attribute:GA --scope=name:*.java.

Tip: Using the si createsandbox and si configuresandbox commands, you can create and edit more complex Sandbox scope

definitions than the GUI using a combination of logical AND or OR operators; however, these definitions may not always be editable from

the GUI. If you attempt to edit a complex scope definition from the GUI, Integrity truncates the definition to what the GUI is capable of

displaying. If you attempt to edit a complex scope definition using the si configuresandbox -g/gui command, Integrity displays a

warning message that choosing to edit the scope definition removes the options the GUI is not capable of displaying

[KaelLizak]

Hello JUAN ERAZO‌,

Were Matthias Rump‌ or Thierry Dalon‌'s responses helpful to you?  If they resolved your issue, could you mark the appropriate response as helping resolve your issue by clicking on Correct Answer at the bottom of the appropriate post?  If it didn't resolve your issue, could you let us know what additional information might be helpful for you?  This lets others running into your issue get an idea of what information was most useful to you, and acknowledges the help of other contributors in the Community.

Thanks,

Kael

[kthierer]

If I understand you right the affected files should also not exist in the filesystem.

If this is right you might consider working with development paths

1.) Make sure that you have a current (or a well known) checkpoint of the corresponding project

2.) Create a development path starting from a checkpointed project revision

3.) Create a variant sandbox with the development path created in step 2

4.) Simply drop the members you don't need. They wont be dropped from the mainline project.

     Jürgen

[mrump]

Hi Jürgen,

The problem of the development path approach is, that you will now have a synchronize two different projects.

A development path is a "deep copy" of all the configured content of a project.

Once created it's development is completely detached from it's parent (e.g. mainline).

As a result you will not automatically participate in any changes made on the parent project.

Depending on your use case this behaviour might be desired.

But for the "filtering" usecase a Juan described, I would definitly recomment the "sandbox scope".

HTH Matthias

[kthierer]

Hi Matthias

Yes you're right, if you plan to use development paths it would be good to have some experience with them (<--> ).

This is definitely worth a warning!

On the other hand "paticipating in changes" does not always mean profiting from changes.

"completely detached" is a hard word:

- from the variant sandbox you can see changes in the mainline as long you did not branch with a member.

  (ok you have to react manually if you want to get up to date)

- unfiltered project history views always show all checkpoints (mainline and variants)

- you can compare 2 checkpoints

- ...

Anyhow there is a certain probability that the filters for a "scoped sandbox" can have influence on the result/build

of the product.

In this case, I would also recommend to use Integrity to maintain the creation scripts for the scoped sandboxes.

(with comments for versions of CLI and all the stuff)

     Jürgen