Cannot find change - How to prevent?

[Ivan Nunes]

Hi

I have suffered from this situation and am still not sure how to prevent it.

Cannot find change 8d6e24e4337ca7208891aa6d8267e43dd073408d (create_table_lookup_table_sym) in sqitch.plan'

Manually, I can fix this by just swapping the place change in the "sqitch.plan" file.

Highlights the changes that have changed place.

Before:

fct_copy_nrtab_seguro_20180129 2018-01-29T17:49:21Z Gilmar de Castro <gilmar...@oi.com.br> # Criando funcao fct_copy_nr
tab_seguro
altera_trigger_prop_loc 2018-01-30T19:18:04Z Orlando Saboia <orlando...@oi.com.br> # [CARTAO_PROP_LOC] trigger alterada
create_table_lookup_table_sym 2018-01-30T21:52:38Z Ivan Nunes <ivan....@oi.com.br> # Add table for routing on Symmetricds
criar_fct_gera_pgresc23a 2018-01-31T17:01:21Z sergio.sousa <sergio...@oi.com.br> # criar funcao para gerar do relatorio
rcai23a
fct_trg_cc_lanc4_v1 2018-01-31T13:58:45Z Ivan Nunes <ivan....@oi.com.br> # Define o servidor de origem pelo valor da func
ao Current_Database
symds_contrato 2018-01-31T18:28:20Z Ivan Nunes <ivan....@oi.com.br> # Adapta trigger para replicar pelo SymDS

After Repair:

fct_copy_nrtab_seguro_20180129 2018-01-29T17:49:21Z Gilmar de Castro <gilmar...@oi.com.br> # Criando funcao fct_copy_nr
tab_seguro
create_table_lookup_table_sym 2018-01-30T21:52:38Z Ivan Nunes <ivan....@oi.com.br> # Add table for routing on Symmetricds
altera_trigger_prop_loc 2018-01-30T19:18:04Z Orlando Saboia <orlando...@oi.com.br> # [CARTAO_PROP_LOC] trigger alterada
criar_fct_gera_pgresc23a 2018-01-31T17:01:21Z sergio.sousa <sergio...@oi.com.br> # criar funcao para gerar do relatorio
rcai23a
fct_trg_cc_lanc4_v1 2018-01-31T13:58:45Z Ivan Nunes <ivan....@oi.com.br> # Define o servidor de origem pelo valor da func
ao Current_Database
symds_contrato 2018-01-31T18:28:20Z Ivan Nunes <ivan....@oi.com.br> # Adapta trigger para replicar pelo SymDS

Last lines in my table "changes":

b6e341437ecf2998dfecfa544fcce18a2ac20249 |e73318b07e1df60858205f7ae389fe4c51414107 |2018-01-29 12:04:27 |trigger_fct_trg_tablojagar_contabil_20180129

273236e5bf4927283f6d6aad576b4f75b05f7e2b |4f96ec225ef0a4fd01f99972245e912cd7efd8b9 |2017-12-26 16:29:52 |criar_campos_cheque                         

7dfc1c43936a258ebaf2f61cbd9f33da85ef9fde |aa5d04ab1635bc02a32401b89b845e532a444ef3 |2018-01-10 09:14:23 |criar_campos_contabilpreju                  

ffeafabba5d7cab371406aecbf50f013238959ce |b5dad65ea4440d87ade9f56c296fc893d892e5ed |2018-01-10 10:23:40 |alter_table_cubagem_old_20180110            

e4f7629be350178f39923eec43fa57e359043ab0 |2230931edb6e145885f9de888ce13c88d66557c1 |2018-01-10 11:06:16 |alter_trigger_fct_trg_cubagem_20180110      

061e5894a711b2cc5107e12e230c66d278465c21 |49b90554f2430cd16f13459077b6b995eb38d96d |2018-01-10 11:20:00 |trigger_fct_trg_cubagem_del                 

928c0affd0110f3ce706447886e7f86bb3d3545b |46cfbf3b42d9b1fb7b3e7e67a444b43baec2cc8e |2018-01-10 11:48:01 |trg_cubagem_del                             

5fba67971a45a8e4fe45b1b85357d176c1e83023 |a5bb9da401c0a062d004144396d1e13b1b9f66de |2018-01-10 15:23:32 |celular_old_20180110                        

70fffd0fbbba9acf86ba8853bddb26d1f4b55e38 |4a576ac2071b880fe03c33807e9927b9602cf022 |2018-01-10 15:44:07 |trigger_fct_trg_celular_del_20180110        

2e5ce5d9953f0e09c0d1bbc6d46c386858b88dca |13800c04c9c0f1e5a663e38acc7a70756db74c89 |2018-01-10 15:54:35 |trg_celular_del_20180110                    

9d1645c6353cf4f5b184209b815abfc4130787bd |e043de08d0b5ee96a09509d180ff34765d9aa8ec |2018-01-10 16:16:26 |trigger_fct_trg_celular                     

62edec3a4ac50f9fef2d05c3049475311abd3ea0 |d6ddf3abf4214bf13610775bbe5bb3ebefbbfb25 |2018-01-10 17:03:06 |fct_set_var_20180110                        

0a9505b309f50037a33a9b0484f5d98fe283708f |1dcfcc0307a3c169b3369045e58da55b0acce39c |2018-01-10 17:11:32 |fct_get_var_20180110                        

34563c1079dac9e788fbad1e6b1d14554a1472e9 |85a38521997569faebe2045aa0ccf91fff31ed0c |2018-01-19 11:56:28 |alter_table_exp_carro                       

ff63cc5419da57e1a9d5e2b46ed25c8727d882ed |3a808b53d287ce442572734327a8a70861fef384 |2018-01-23 11:41:29 |alter_table_exp_carrego_20180123            

7605ce309cb71f1a9a7ecbd0c5fc615b594b7ecd |ec04b420dcc091142d385df830c5a7f2aeec49ea |2018-01-29 12:06:01 |trg_tablojagar_20180129                     

6d3b89010cd452b953dcd383282e14a60ec47bc9 |7a52ea604b6e713bbaec922f8988114a7b2bcc31 |2018-01-29 12:07:24 |trg_tablojagar_contabil_20180129            

b30e7f68fc2dce16b3f4415868ae4d3ca9519c68 |139fc9d50c6c36dddcb06f4132e8e97e4ad3f686 |2018-01-29 14:49:21 |fct_copy_nrtab_seguro_20180129              

[David E. Wheeler]

On Feb 1, 2018, at 07:34, Ivan Nunes <ivanels...@gmail.com> wrote:

> I have suffered from this situation and am still not sure how to prevent it.
>
> Cannot find change 8d6e24e4337ca7208891aa6d8267e43dd073408d (create_table_lookup_table_sym) in sqitch.plan'
>
> Manually, I can fix this by just swapping the place change in the "sqitch.plan" file.

Did you swap them after deploying? Because that shouldn’t happen if you haven’t changed the plan file.

Sqitch is quite careful to ensure that the order of deployments never changes once you’ve made a deploy. If you deployed a plan with changes A and B, then edited the plan file so that B comes before A, deploys will not work anymore. This is intentional to try to assure the reliability of production deploys.

If you’re just messing around while doing development, however, you can just rebase (reverts then deploys again)

Best,

David

[Ivan Nunes]

Hi David

I can not believe that the plan file was modified manually after the deployment.

I read the [1] tutorial again and I'm almost certain that this occurs because of lack of attention or carelessness with the branches.

From what i understand:

- The repository should always have this configuration:

$ echo sqitch.plan merge = union> .gitattributes

- Always before pushing, the developer should do "pull -rebase" in the local branch.

$ git pull --rebase master

- After this check the order of the changes in the plan file (sqitch.plan), if the local change appears as the last one in the plan, then you can push.

I think that's it.

[1] https://metacpan.org/pod/sqitchtutorial#Emergency

Kind regards

[David E. Wheeler]

On Feb 5, 2018, at 08:08, Ivan Nunes <ivanels...@gmail.com> wrote:

> I think that's it.

Yes, that might do it. If a merged change somehow was not appended to the end of the plan, you could certainly end up in the situation you describe.

D

[Timo Stolz]

I had similar issues. Is it still advisable to use union merges, if the incoming changes are not guaranteed to be added at the end of sqitch.plan? When I'm asked to resolve the conflict manually, I can ensure that incoming changes are always appended, and thus do not break existing parent-child-relationships. When I rely on union merges, then the docs (https://git-scm.com/docs/gitattributes#Documentation/gitattributes.txt-union) clearly state "This tends to leave the added lines in the resulting file in random order and the user should verify the result."

However, since union merges are silently, I'm not forced (nor prompted) to verify the result, and changes easily slip in out of order.

What do you recommend in such situations? Will rebase still work? (I'm in doubt, because the added changes cannot be reverted, since they were never deployed.) And if it would still work, what would you recommend in

situations where rebases are a no-option, e.g. production databases?

[David E. Wheeler]

On Aug 3, 2021, at 5:55 AM, 'Timo Stolz' via Sqitch Users <sqitch...@googlegroups.com> wrote:

> I had similar issues. Is it still advisable to use union merges, if the incoming changes are not guaranteed to be added at the end of sqitch.plan? When I'm asked to resolve the conflict manually, I can ensure that incoming changes are always appended, and thus do not break existing parent-child-relationships. When I rely on union merges, then the docs (https://git-scm.com/docs/gitattributes#Documentation/gitattributes.txt-union) clearly state "This tends to leave the added lines in the resulting file in random order and the user should verify the result."

In practices I have not used union merges, as the issue has rarely come up. And as you say, it’s straightforward to resolve manually. But IME union merges always append the new lines to the end of the file, but I also haven’t tried it when there are multiple changes in both branches.

> However, since union merges are silently, I'm not forced (nor prompted) to verify the result, and changes easily slip in out of order.

Yes, true. I also rely on CI to catch stuff like this, tho.

> What do you recommend in such situations? Will rebase still work?

I recommend you do what works best for you and other members of your team.

> (I'm in doubt, because the added changes cannot be reverted, since they were never deployed.)

I don’t understand this sentence.

> And if it would still work, what would you recommend in
> situations where rebases are a no-option, e.g. production databases?

I recommend that you your project thoroughly before releasing. I have followed patterns where I have thoroughly tested the plan and make no changes to it (other than tagging) before releasing. Merge conflicts are not even relevant by this point.

Best,

David