Ninjascript Version Control and Production enviornment

[llanqui]

Hello,

What is the preferred/suggested method to manage NinjaScript libraries?

because it seems that when a new version of an indicator is put onto a production machine, say perhaps by a file system overwrite into the Ninja Folder

or otherwise in the production system one must delete the ninjascript and then save the new version (which has a different name) to the name of the one deleted....

but both of these apparently deletes all reference to the ninjascript thruout the Ninja system, in all workspaces, templates.

then one has to restore the workspace setups and the templates.

so....am I doing something incorrect?

I am in constant development/improvement and need to do this often.


How can I put new code into production (i.e. on the trading computer), replacing/updating ninjacripts with a new version without Ninja deleting the internal references? (i.e. in the charts, templates, workspaces, et cetera)

For example,

I have xxxxxx.cs in production

and a new version called xxxxxxx01.cs tested and ready to replace xxxxxx.cs

How do I do that?

Thanks

[QuantKey_Bruce]

Well, you raise some good questions. I would like to ask a clarifying question - instead of constantly renaming the working indicator or strategy on your development computer and having one name on your trading computer, what if, at the start of each development cycle, you simply "save as" the working one to a different name with a date or version number e.g. save as "xxxxxxx01.cs" but continue developing on "xxxxxxx.cs"? Or, alternatively, what if you didn't have dozens or hundreds of .cs versions installed but used source control e.g. GitHub or whatever to manage your past versions? It seems to me you may be making a false assumption here that the best thing is to keep changing the name of the working file. I would posit that what you really want to do is keep working on the same file, but keep backups at intervals or before each sprint or stage (either in source control or low tech with save as with a date or version number) so you can revert or compare as needed. Does that make sense? If you were to do it that way, you would not have a need to try to change all of the charts, templates, workspaces, etc. as you say.

[llanqui]

Hello Bruce,

Well, I just recently ported my whole NT7 system to NT8...a lot of code.

On NT7 I could just overwrite the production CS file and recompile. I had two machines, a Developer and a Trader. I would just copy the CS from the Developer to Trader machine (overwrite with File Manager), recompile and it worked OK.

But now, I'm in NT8 and I prefer to do all the development on my Trader machine. This is because the Trader machine is faster, better, nicer, and Windows 10. NT8 is a big improvement over NT7, for sure.

When I want to create a working copy (a new version) , I bring up say XXXXX.cs and save it as XXXXX01.cs.

And, continue to use XXXXX.cs as the production code.

Thus XXXXX01 is my test code and is not part (yet) of my trading system. (compiled but not linked into my archetecture)

This way all my charts, templates, et cetera, do not have to be repointed to another name.

Now, when I'm ready to put XXXXX01.cs into production, it would be with the original name...that is XXXXX.cs

But, the Ninja Editor will not let me "write over", or "save as" an existing file.

If it would let me do that then this would be solved.

I have to delete the original first, and that removes all the references to it on the charts, templates, etc, and I have to rebuild them.

Or, is there a better way?


One that I will probably end up doing is to have both XXXXX.cs and XXXXX01.cs in the editor

then I will delete all the statements in XXXXX.cs, and copy and paste (into that empty editor) all the statements from XXXXX01.cs.

Then change all references "XXXXX01.cs" there to "XXXXX.cs"

then save the file and compile it.

Should work...but I would not consider this a developer friendly method.

:-)

[QuantKey_Bruce]

One thing you could do, as a hack, is just close all your workspaces. Then, close NT8. Then delete the xxxx.cs file. Then, re-open NT8 and go into the Editor and save as the xxxx.01.cs as xxxx.cs. Then, re-open your workspaces. No references have been lost in templates or workspaces, because they were not open.

[bltdavid]

When I want to create a working copy (a new version) , I bring up say XXXXX.cs and save it as XXXXX01.cs.

And, continue to use XXXXX.cs as the production code.

Thus XXXXX01 is my test code and is not part (yet) of my trading system. (compiled but not linked into my archetecture)

This way all my charts, templates, et cetera, do not have to be repointed to another name.

Now, when I'm ready to put XXXXX01.cs into production, it would be with the original name...that is XXXXX.cs

But, the Ninja Editor will not let me "write over", or "save as" an existing file.

If it would let me do that then this would be solved.

I have to delete the original first, and that removes all the references to it on the charts, templates, etc, and I have to rebuild them.

Or, is there a better way?

Yes.

I'd suggest you try using a merge tool to merge the changes from XXXXX01.cs
back to XXXXX.cs.

I use WinMerge to do this, it is free and it works great.

You could archive your '01' file and use the '02' the next time you want
to make a working copy ... or not.

A source code control tool, like Git, could help with these merges, but I'd
prefer to do them by hand (ie, the '01' working copy has a different class
name that you do not want to merge).

[jeronymite]

There are many good suggestions above. To add to the list, you could also:

• Simply open both files in the editor, then copy/paste the entire contents of the now-ready development version to completely replace the contents of the current version, change the internal naming of the now-updated version to remove duplication with the development version, then recompile
• Or in the platform, rename the current version to something (e.g. ...OLD...) and then rename the development version to the current name, again ensuring internal name consistency
• Or close NT8, rename the files to be as you want, again ensure internal naming consistency to avoid duplication, and you're good to go

The consistency checks (mainly internal to ensure correct name recognition in the platform) are important, but not at all onerous. Just a few extra thoughts to try to ease the pain.

Thanks.

[llanqui]

Thanks Guys, enough here to get me on the right track..