Planning Analytics

Started to play with the Git integration functionality ( https://www.ibm.com/docs/en/planning-analytics/2.0.0?topic=mipaw-use-git-repository-integration-manage-planning-analytics-database-objects ) and I have a question that I thought I'd ask here before going the support route. Maybe @STUART KING or @Svetlana Pestsova can chime in whether it's a bug or a feature? Testing on IBM PaoC, so all on the reasonably latest versions (11.8.01900.10)

I'm doing the following:
1) push a TI to a repository branch A
2) change the T by adding some code
3) run the update of the model from the branch A in the repository
and instead of reverting the TI to the state when it was pushed, the TI is skipped for update

If I add a step
2.5) push a TI to a repository branch B
after doing the changes and then try pulling from the branch A again, it does show the change and revert the TI to the state when it was pushed to A.

It seems a bit inconsistent and can cause some confusion, so I wanted to check if that's the desired behaviour? 
Judging by what what I see in the `}git.ctx` file it looks like pull / "update model from repository" doesn't recalculate object hashes of the local instance, only push / "add objects to repository" does. It's a bit different to how canonical git pull works, it does compare hashes of local vs remote to determine changes.

PS: this PAW integration for Git is amazing and something I've been writing Santa about for a while now, big thanks to IBM team for delivering it! Xmas in July is something we celebrate down under and it's not even July, an early prezzie for me :)

Hi Yuri,

 Great question. I was noticed that too. While the implementation doesn't match what I would expect from using GitHub with other programming languages, I think I like it and I'll explain why. 

 The existing model for change control in PA is some fashion of using subfolders to group objects that are ready for promotion. We then copy those from one environment to another, restart the service, and pray that it worked. The model in PA seems to use feature branches and environment branches in a slightly different way. This approach solves the problem of multiple people making changes in the same environment, outside of change control.

 Consider this scenario.
  1) push all objects from prod to an environment branch (prod)
  2) push all objects from dev to an environment branch (dev)
  3) change a TI in dev
  4) push JUST the TI to a feature branch (dev-1234)
  5) pull JUST the TI from the feature branch to prod (dev-1234)
  6) Oops, I broke something, I can now pull my prod branch (prod) to rollback everything

 I agree that the expected behaviour of pulling from an old repository branch should overwrite the existing files, but it looks like this is done differently here to try not to overwrite something that may have been changed outside source code control.

...then again, I could be completely wrong. :-)  

------------------------------
Bob Gill

Original Message:
Sent: Wed May 24, 2023 08:06 AM
From: Yuri Kudryavcev
Subject: Git update model from repository doesn't revert changes made after adding objects to a branch?

Started to play with the Git integration functionality ( https://www.ibm.com/docs/en/planning-analytics/2.0.0?topic=mipaw-use-git-repository-integration-manage-planning-analytics-database-objects ) and I have a question that I thought I'd ask here before going the support route. Maybe @STUART KING or @Svetlana Pestsova can chime in whether it's a bug or a feature? Testing on IBM PaoC, so all on the reasonably latest versions (11.8.01900.10)

I'm doing the following:
1) push a TI to a repository branch A
2) change the T by adding some code
3) run the update of the model from the branch A in the repository
and instead of reverting the TI to the state when it was pushed, the TI is skipped for update

If I add a step
2.5) push a TI to a repository branch B
after doing the changes and then try pulling from the branch A again, it does show the change and revert the TI to the state when it was pushed to A.

It seems a bit inconsistent and can cause some confusion, so I wanted to check if that's the desired behaviour? 
Judging by what what I see in the `}git.ctx` file it looks like pull / "update model from repository" doesn't recalculate object hashes of the local instance, only push / "add objects to repository" does. It's a bit different to how canonical git pull works, it does compare hashes of local vs remote to determine changes.

PS: this PAW integration for Git is amazing and something I've been writing Santa about for a while now, big thanks to IBM team for delivering it! Xmas in July is something we celebrate down under and it's not even July, an early prezzie for me :)

------------------------------
Cheers,
Yuri
------------------------------

Hi Yuri and Bob,

Local changes are always kept in our implementation when there is a conflict.
This is by design. 
If the user resets the Git connection it would reset the Git context; then it could be overwritten by the remote. 

Hi Yuri,

 Great question. I was noticed that too. While the implementation doesn't match what I would expect from using GitHub with other programming languages, I think I like it and I'll explain why. 

 The existing model for change control in PA is some fashion of using subfolders to group objects that are ready for promotion. We then copy those from one environment to another, restart the service, and pray that it worked. The model in PA seems to use feature branches and environment branches in a slightly different way. This approach solves the problem of multiple people making changes in the same environment, outside of change control.

 Consider this scenario.
  1) push all objects from prod to an environment branch (prod)
  2) push all objects from dev to an environment branch (dev)
  3) change a TI in dev
  4) push JUST the TI to a feature branch (dev-1234)
  5) pull JUST the TI from the feature branch to prod (dev-1234)
  6) Oops, I broke something, I can now pull my prod branch (prod) to rollback everything

 I agree that the expected behaviour of pulling from an old repository branch should overwrite the existing files, but it looks like this is done differently here to try not to overwrite something that may have been changed outside source code control.

...then again, I could be completely wrong. :-)  

Started to play with the Git integration functionality ( https://www.ibm.com/docs/en/planning-analytics/2.0.0?topic=mipaw-use-git-repository-integration-manage-planning-analytics-database-objects ) and I have a question that I thought I'd ask here before going the support route. Maybe @STUART KING or @Svetlana Pestsova can chime in whether it's a bug or a feature? Testing on IBM PaoC, so all on the reasonably latest versions (11.8.01900.10)

I'm doing the following:
1) push a TI to a repository branch A
2) change the T by adding some code
3) run the update of the model from the branch A in the repository
and instead of reverting the TI to the state when it was pushed, the TI is skipped for update

If I add a step
2.5) push a TI to a repository branch B
after doing the changes and then try pulling from the branch A again, it does show the change and revert the TI to the state when it was pushed to A.

It seems a bit inconsistent and can cause some confusion, so I wanted to check if that's the desired behaviour? 
Judging by what what I see in the `}git.ctx` file it looks like pull / "update model from repository" doesn't recalculate object hashes of the local instance, only push / "add objects to repository" does. It's a bit different to how canonical git pull works, it does compare hashes of local vs remote to determine changes.

PS: this PAW integration for Git is amazing and something I've been writing Santa about for a while now, big thanks to IBM team for delivering it! Xmas in July is something we celebrate down under and it's not even July, an early prezzie for me :)

Hi Yuri and Bob,

Local changes are always kept in our implementation when there is a conflict.
This is by design. 
If the user resets the Git connection it would reset the Git context; then it could be overwritten by the remote. 

We'd add the explanation to our documentation and also later maybe provide the option to developers to do the reset automatically.

------------------------------
Svetlana Pestsova
IBM Planning Analytics Product Manager

Original Message:
Sent: Wed May 24, 2023 12:24 PM
From: Bob Gill
Subject: Git update model from repository doesn't revert changes made after adding objects to a branch?

Hi Yuri,

 Great question. I was noticed that too. While the implementation doesn't match what I would expect from using GitHub with other programming languages, I think I like it and I'll explain why. 

 The existing model for change control in PA is some fashion of using subfolders to group objects that are ready for promotion. We then copy those from one environment to another, restart the service, and pray that it worked. The model in PA seems to use feature branches and environment branches in a slightly different way. This approach solves the problem of multiple people making changes in the same environment, outside of change control.

 Consider this scenario.
  1) push all objects from prod to an environment branch (prod)
  2) push all objects from dev to an environment branch (dev)
  3) change a TI in dev
  4) push JUST the TI to a feature branch (dev-1234)
  5) pull JUST the TI from the feature branch to prod (dev-1234)
  6) Oops, I broke something, I can now pull my prod branch (prod) to rollback everything

 I agree that the expected behaviour of pulling from an old repository branch should overwrite the existing files, but it looks like this is done differently here to try not to overwrite something that may have been changed outside source code control.

...then again, I could be completely wrong. :-)  

------------------------------
Bob Gill

Original Message:
Sent: Wed May 24, 2023 08:06 AM
From: Yuri Kudryavcev
Subject: Git update model from repository doesn't revert changes made after adding objects to a branch?

Started to play with the Git integration functionality ( https://www.ibm.com/docs/en/planning-analytics/2.0.0?topic=mipaw-use-git-repository-integration-manage-planning-analytics-database-objects ) and I have a question that I thought I'd ask here before going the support route. Maybe @STUART KING or @Svetlana Pestsova can chime in whether it's a bug or a feature? Testing on IBM PaoC, so all on the reasonably latest versions (11.8.01900.10)

I'm doing the following:
1) push a TI to a repository branch A
2) change the T by adding some code
3) run the update of the model from the branch A in the repository
and instead of reverting the TI to the state when it was pushed, the TI is skipped for update

If I add a step
2.5) push a TI to a repository branch B
after doing the changes and then try pulling from the branch A again, it does show the change and revert the TI to the state when it was pushed to A.

It seems a bit inconsistent and can cause some confusion, so I wanted to check if that's the desired behaviour? 
Judging by what what I see in the `}git.ctx` file it looks like pull / "update model from repository" doesn't recalculate object hashes of the local instance, only push / "add objects to repository" does. It's a bit different to how canonical git pull works, it does compare hashes of local vs remote to determine changes.

PS: this PAW integration for Git is amazing and something I've been writing Santa about for a while now, big thanks to IBM team for delivering it! Xmas in July is something we celebrate down under and it's not even July, an early prezzie for me :)

------------------------------
Cheers,
Yuri
------------------------------

Hi @Svetlana Pestsova ,

Thank you for the update!

re "We'd add the explanation to our documentation"
May I suggest adding a clarification to this sentence 
"The GitPullPlan dynamically determines the actions to be done to deploy the source, based on the Git context, the hash of the source, and the hash of the server object. An action could be to create an object, to execute a TI or to set configurations, etc."
in the Rest API call documenation
to say "hash of the source as stored in the Git context (i.e. updated on last push)"?

Hi Yuri and Bob,

Local changes are always kept in our implementation when there is a conflict.
This is by design. 
If the user resets the Git connection it would reset the Git context; then it could be overwritten by the remote. 

We'd add the explanation to our documentation and also later maybe provide the option to developers to do the reset automatically.

------------------------------
Svetlana Pestsova
IBM Planning Analytics Product Manager

Original Message:
Sent: Wed May 24, 2023 12:24 PM
From: Bob Gill
Subject: Git update model from repository doesn't revert changes made after adding objects to a branch?

Hi Yuri,

 Great question. I was noticed that too. While the implementation doesn't match what I would expect from using GitHub with other programming languages, I think I like it and I'll explain why. 

 The existing model for change control in PA is some fashion of using subfolders to group objects that are ready for promotion. We then copy those from one environment to another, restart the service, and pray that it worked. The model in PA seems to use feature branches and environment branches in a slightly different way. This approach solves the problem of multiple people making changes in the same environment, outside of change control.

 Consider this scenario.
  1) push all objects from prod to an environment branch (prod)
  2) push all objects from dev to an environment branch (dev)
  3) change a TI in dev
  4) push JUST the TI to a feature branch (dev-1234)
  5) pull JUST the TI from the feature branch to prod (dev-1234)
  6) Oops, I broke something, I can now pull my prod branch (prod) to rollback everything

 I agree that the expected behaviour of pulling from an old repository branch should overwrite the existing files, but it looks like this is done differently here to try not to overwrite something that may have been changed outside source code control.

...then again, I could be completely wrong. :-)  

------------------------------
Bob Gill

Original Message:
Sent: Wed May 24, 2023 08:06 AM
From: Yuri Kudryavcev
Subject: Git update model from repository doesn't revert changes made after adding objects to a branch?

Started to play with the Git integration functionality ( https://www.ibm.com/docs/en/planning-analytics/2.0.0?topic=mipaw-use-git-repository-integration-manage-planning-analytics-database-objects ) and I have a question that I thought I'd ask here before going the support route. Maybe @STUART KING or @Svetlana Pestsova can chime in whether it's a bug or a feature? Testing on IBM PaoC, so all on the reasonably latest versions (11.8.01900.10)

I'm doing the following:
1) push a TI to a repository branch A
2) change the T by adding some code
3) run the update of the model from the branch A in the repository
and instead of reverting the TI to the state when it was pushed, the TI is skipped for update

If I add a step
2.5) push a TI to a repository branch B
after doing the changes and then try pulling from the branch A again, it does show the change and revert the TI to the state when it was pushed to A.

It seems a bit inconsistent and can cause some confusion, so I wanted to check if that's the desired behaviour? 
Judging by what what I see in the `}git.ctx` file it looks like pull / "update model from repository" doesn't recalculate object hashes of the local instance, only push / "add objects to repository" does. It's a bit different to how canonical git pull works, it does compare hashes of local vs remote to determine changes.

PS: this PAW integration for Git is amazing and something I've been writing Santa about for a while now, big thanks to IBM team for delivering it! Xmas in July is something we celebrate down under and it's not even July, an early prezzie for me :)

------------------------------
Cheers,
Yuri
------------------------------