Skip to main content
J
jerazo1-Visitor
1-Visitor
March 8, 2016
Solved

How can I remove a specific file from a sandbox?

  • March 8, 2016
  • 1 reply
  • 6168 views

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.

    Best answer by tdalon

    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

    1 reply

    M
    mrump16-Pearl
    16-Pearl
    March 9, 2016

    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

    J
    jerazo1-VisitorAuthor
    1-Visitor
    March 9, 2016

    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.

    T
    tdalon1-VisitorAnswer
    1-Visitor
    March 10, 2016

    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

    Terms & ConditionsCookie settingsAccessibility statement