Page 1 of 2
VO versions
Posted: Thu Sep 22, 2022 7:56 pm
by NickFriend
HI all,
A quick question about VO versions. I have 2.8 SP2a (2831). I need to copy a repository to someone with 2.8 SP4b (2838).
If we try simply copying, we're getting a Version mismatch error 40256 - is that just because it's marked as 2831 in the voprj file, or are the repositories actually different between these versions? I know we can export to AEFs and import, but I want to avoid that.
If it's just the voprj file I imagine I can simply edit it, otherwise we'll have to make sure we're on the same version.
Thanks
Nick
VO versions
Posted: Fri Sep 23, 2022 3:29 am
by wriedmann
Hi Nick,
it is never a good idea to copy repositories even if you are on the same version.
The easiest possibility would be to have all handwritten code in external prg files and copy only them.
This is what I'm doing on my main libraries. But this does not works on modules with binary entities.
They have to be exported/imported.
Otherwise you have to export and import AEFs (Paul Pikos VO Productivity Pack does a great job with this).
Wolfgang
VO versions
Posted: Fri Sep 23, 2022 5:22 am
by robert
Nick,
What Wolfgang said.
Robert
VO versions
Posted: Fri Sep 23, 2022 8:19 am
by NickFriend
Some context may be useful.
I do all the programming (remotely), but the head office needs a failsafe so that if I get run over by a bus they have the source code and can continue to compile it as needed. So we're not sharing programming, just getting an easily useable copy of the code to a safe place. I have a backup system which takes regular copies of the repository directory and copies it to a shared OneDrive folder.
I only need to use VO infrequently, and import/export of a whole bunch of AEFs is not very user friendly or efficient (we don't have VOPP). Given that the repository is just a bunch of files, I don't see why copying it should be any less reliable than exporting each module and copying those files??... and the process I have is completely automated and with multiple backups available (in case one fails for some reason).
Given this... back to the original question
Nick
VO versions
Posted: Fri Sep 23, 2022 8:33 am
by wriedmann
Hi Nick,
then you should invest in a copy of VOPP and copy the resulting AEFs regularly to GitHub as I do.
Copying the repository is unreliable because it is not sure that you will be able to reconstruct the code on another machine with a different directory and/or VO version.
Wolfgang
VO versions
Posted: Fri Sep 23, 2022 8:52 am
by NickFriend
wriedmann post=23995 userid=336 wrote:Copying the repository is unreliable because it is not sure that you will be able to reconstruct the code on another machine with a different directory
Really?... why not? If the other install is exactly the same version (this was the root of the original question), and you open a project by navigating to its folder and selecting the voprj file, why should they not be able to reliably access my code? Ignore issues like location of icon files, etc... just focusing on the source code.
Nick
VO versions
Posted: Fri Sep 23, 2022 9:51 am
by ic2
Hello Nick,
Kees copies my full zipped repo directory from time to time, checks if all his changes he sent have been included by me and it has always worked 100%.
But it could be a good idea to also export the AEF's; it is easy to import AEF's in an empty repo (as the later VO's first create empty entries if absent and then overwrite when the actual AEF is imported) but building the project is many times faster, as it is automated, in VOPP.
Dick
VO versions
Posted: Fri Sep 23, 2022 2:37 pm
by robert
Nick,
NickFriend post=23994 userid=745 wrote:Some context may be useful.
I do all the programming (remotely), but the head office needs a failsafe so that if I get run over by a bus they have the source code and can continue to compile it as needed. So we're not sharing programming, just getting an easily useable copy of the code to a safe place. I have a backup system which takes regular copies of the repository directory and copies it to a shared OneDrive folder.
I only need to use VO infrequently, and import/export of a whole bunch of AEFs is not very user friendly or efficient (we don't have VOPP). Given that the repository is just a bunch of files, I don't see why copying it should be any less reliable than exporting each module and copying those files??... and the process I have is completely automated and with multiple backups available (in case one fails for some reason).
Given this... back to the original question
Copying the repo is safe, as long as you make sure that external files (bmp, ico etc) are also copied.
However you will have to consume the repo with the same version in which it was created.
2.8 SP2 and 2.8 SP4 are binary incompatible
I would have given these versions a complete new version number, but in the contract between Brian and CA is was stated stated that if Brian created a new version number (2.9) then he had to send more money to Computer Associates. And of course he did not want to do that.
Robert
VO versions
Posted: Fri Sep 23, 2022 6:58 pm
by Jamal
Nick,
Since VO28 has no Windows registry keys to worry about, so may be copying the C:CAVO28 folder to a different folder,example: C:CAV28-2831, would do the trick.
So, basically you will have the different versions side by side. Hope this works for you!
Jamal
VO versions
Posted: Fri Sep 23, 2022 10:33 pm
by NickFriend
Thanks for the info Robert, that's more or less what I suspected.
Nick