Ignore version dependencies for viewpath or file

[RicardoBernardino]

Hello.

 

In behalf of a customer, I have a tricky question.

I am trying to find a way to remove dependencies between files with no real logical or technical dependency except the location and name, so they don't prevent package promotions due to those dependencies.

Is it possible to verify package dependency of all repository except for a specific folder?

If not, can you suggest an alternative way to not version a group of files, like the one checked into a specific view path?

 

Can form attachments be an alternative? If yes, how can we control the accesses to them?

 

Below, I have an example.

I have two packages of the same project, with nothing in common except one file (Install_modules.xml):

Package 1

\sourcecode\ComponentA.source (v23)

\sourcecode\ComponentB.source (v21)

\bin\ComponentA.bin (v23)

\bin\ComponentB.bin (v21)

\deploy\Install_modules.xml (v06)

Package 2

\sourcecode\ComponentC.source (v16)

\sourcecode\ComponentD.source (v20)

\bin\ComponentC.bin (v16)

\bin\ComponentB.bin (v20)

\deploy\Install_modules.xml (v07)

 

Best regards,

Ricardo Bernardino

[Melinda Skelton]

In Harvest, package promotions can be hindered by two different types of dependencies.

 

The first type is between different versions of the same item.  In general, you can't promote a later version of an item before promoting the earlier version.

 

The second type is between an item and the folder it's in.  The folder must be promoted first, so that it exists in the next state before items within the folder can be promoted.

 

It looks like, in your case, it's the first type of dependency.  Do you mean to say that version 6 of the "deploy\Install_modules.xml" file is not at all related to version 7 of the same file?  If there is truly no relation between the two, you might consider a couple of options:

- One would be to change the name of the file and check it in as a new item

- Another possibility, if the name must be the same is to perform "Remove Item" on the file, creating a "D"-tagged version, then checking it in again as new item

If the files really are successive versions of the same file, but you don't want this to hinder package promotion you could do one of these things:

- Uncheck the "Verify Dependencies" checkbox to prevent the dependency check

- Use the "Switch Package" process to move this file to a different package

 

Let me know if this helps.

[RicardoBernardino]

Hello, MelindaS

Uncheck the Verify Dependencies checkbox or use the processes suggested (Switch Package and Remove Item) is not a valid solution for me.

 

As a last resort, defining a different name for the file in each package or attach it to a form.

In this case, I would like to know if this is a possible alternative for this case, due to the lack of access control properties to the form attachments, as I asked in the end of my post:

Can form attachments be an alternative? If yes, how can we control the accesses to them?

 

Best regards,

Ricardo Bernardino

[Robert_Thornburrow]

In Harvest a package is defined as a collection of related changes.  Not only is there an dependency between successive versions of the same item, but there is also an implicit dependency between versions checked into the same package.  This means that if Package A contains A.java;3, package B contains A.java;2 and B.java;1, and package C contains B.java;0, then in order to promote package A, you will need to promote package C, even though it seems unrelated.

 

If there is no relationship between the items in the package, then they are really separate changes and should be in separate packages.  If you want to make a relationship between them, so that they all get promoted together, then make the packages into a bound package group.  Provided that you "enforce package bind" on the promote, the packages then cannot be move independently of one another.  To promote all the packages, you just run the promote from the package group.

 

The only other way to get Harvest to not care about dependencies is to turn off the "verify package dependency" on the promote process, which you have already said you cannot do.  However, just because you turn it off does not mean you cannot replace it with a mechanism of your own that runs as a pre-linked UDP.  If you do that, then you can enforce whatever rules you want.

 

Best regards,

 

     R.