How to best organize a private project for easy update?
Posted 24 April 2012 - 10:56 PM
As long as i only add scripts - no problem to update.
But i replaced or changed a lot of scripts, so they get constantly wiped out.
I could just copy them back in, but this sometimes breaks things.
So i have to keep 3 projects.
The old and the updated one to check what changed, before adding the updates to my project.
Has anyone come up with a simpler or easier solution?
Posted 25 April 2012 - 01:20 AM
using the project dir or winbuilder dir as your repo. you can then diff (inspect/compare) and merge individual or multiple scripts and have the ability to revert back to individual scripts or changes if something is broke. using branch you can span off test builds for new scripts/features without mucking up the trunk and tag for when you get that perfect build so you can always jump back if you want a fresh start.
using the diff/merge feature is especially nice as you can see what changed in a particular broken script or weather your version is better and should be used instead.
there is a little bit of a learning curve and midset ajustment but svn has been around for ages and there is lots of tutorials and such floating around.
Posted 25 April 2012 - 09:35 AM
I just don't see, how it can be applied to my problem.
Posted 25 April 2012 - 10:34 AM
- Where you actually are developing the project
- From where you upload.
"Changed" is intelligent. So e.g. a check / uncheck in the GUI interface is not seen as change. (You can force a copy of any script by manually increasing the version in the development script.)
It does some other tasks like
- Delete your private data, e.g. %SourceDir%
- Delete build-created variables
- Reset "Factory Settings"
- Certify the script to upload
As far as I understood your first post, that's what you need.
Posted 25 April 2012 - 01:20 PM
I misunderstood your question.
I just realized "From the server" in your first post.
I have to think about this ...
Posted 25 April 2012 - 03:27 PM
Posted 07 May 2012 - 04:10 AM
The first problem we have (the non-English speakers) is in the translations to be applied to each script, they are contained in each script. For example, name the folder where you created the shortcut to the application (on the start menu).
This could be solved if you enable an ini file with the translation of each route according to the language chosen in WinBuilder. But every script, need modifications to read that file... to preview the result from WinBuilder, and read that file to create the shortcut.
The second problem, the changes we have made in the script. For example ClearLook, the password saved for lock.
This is more complicated because the scripts do not have design rules, as it only checks WinBuilder lines of code, when it's the interpretation, if the job was done correctly or not, but does not apply a pre-test on the design in each script .
This is a plus for freedom in the creation of scripts. But bad for the continued orderly development as a whole.
Also not all the scripts, save the user custom settings, externally to the script. For example in (..WorkbenchCommon).
Easy updating... not so easy....
I always keep a backup of the previous version. (eg. Win7PE_SE_20120216_20120417.z7) [Excluding folders ISO, Logs, Mount, Target, Temp]
I keep the new version in a different folder. ( eg. Win7PE_SE_20120416)
I set the personal settings for each script, as I need.
I make the changes (script by script) for translations in the folders for shortcuts.
But for the applications I use, I created a sub folder where I keep my modified versions of each script (I add here too another scripts manually) and in any case I update each script individually only if I consider it necessary, otherwise... I continue with the version that I have ... knowing that it works.
2-BGInfo.script and ClearLock.script are my modified versions.These are off on their original locations.
No complete updates often. But the update is a problem if we are not accustomed to working in an ordered structure. Since we always forget something and that's going to mean much testing time...
Posted 07 May 2012 - 07:09 AM
1 user(s) are reading this topic
0 members, 1 guests, 0 anonymous users