sync and update...

[SledgehammerPL]

What am I doing wrong.
For my system I use two copies. Devel and Test (Prod would be later :)

I make changes on devel. than I add new *.php, *.yaml, *.htm via svn it to subversion server, than I go to test, sync it down,
I have to change owner of updates/ than I go to winter, apply new version (database changes) - and voila..

BUT... Somewhy during update winter on test creates NEW change file . The only difference is a the end of name of file.

for instance from svn come builder_table_update_party_structure_document_items_6.php and it creates builder_table_update_party_structure_document_items6.php (and of course changing version.yaml).

I don't understand why (and it is annoying...)

[LukeTowers]

I have absolutely no idea what you're talking about. Winter has nothing to do with subversion or syncing changes from it.

[SledgehammerPL]

STUPID ME! The problem is with BUILDER module!

The method of copying files from one server to second is ABSOLUTELY irrelevant. Imagine I copy whole files from one place to another, and then execute upgrade. And upgrade on this second place uses different builder_table_update schema to create - on one place is with '_' and other - without... And I'm asking WHY.

[LukeTowers]

Take a deep breath before responding please. Putting words in all caps is equivalent to shouting them.

If you know an issue is specific to a particular plugin or theme, then please submit that issue in the appropriate repository for that plugin or theme. This repository is only for issues that are associated with the three core Winter CMS modules: Backend, CMS, & System.

The repository you are looking for in this case is https://github.com/wintercms/wn-builder-plugin.

[SledgehammerPL]

Of course I know what caps means. It means shouting but also strong emphasis. But you're absolutely right - I put the question in wrong place (as a beginner in wintercms i use builder very often so I treat it as a unity. And unfortunatelu writing is stripped of emotions. I should write "STUPID ME! The problem is with BUILDER!!!.

I should be much more attentive... So very sorry for being rude.
Please confirm that you read this (with thumb up or sth like this and I will remove whole question because it shouldn't be here at all.

[LukeTowers]

No worries @SledgehammerPL :) I've transferred this discussion to the builder plugin

[bennothommo]

@SledgehammerPL please be respectful. You're asking for a LOT of free advice at the moment (I count 15 separate forum threads in the last month).

If you take a look at the Builder plugin repo, you'll see that the naming issue is a known issue and has to do with the MigrationModel.php::makeScriptFileNameUnique method within the Builder plugin. We're currently busy with other developments, so please feel free to contribute a pull request to that repo if you manage to figure out a fix.

[SledgehammerPL]

Ok, ok. I'm asking many questions, but if you look closer, you will find, that when I found the solution I answer myself - for others having the same problem. I understand that it is open and free, but i want to help make it better. So when I found something unexpected and investigate that it should work different - i share with it.
I'm not expecting help in a minutes. Every question is preceded with digging with documentation and examples. But sometimes documentation makes more confusion that no documentation.

My bad - I totally forgotten that builder is just a module not a core of winter - so I even don't try to find modules documentation.

You're making great job.

(I'll try to check why makeScriptFileNameUnique works different on two machines)

[bennothommo]

We certainly appreciate the effort you're putting into answering the questions, and as long as you're checking the documentation and any past reports of issues first before posting, that's all we ask. 🙂

It just seems sometimes when we don't answer in the way you expect, you get a little sarcastic. (like when you called me a "genius" in one of the other threads)

I apologise if that's not your intent.