VO versions

NickFriend · Post by **NickFriend** » Thu Sep 22, 2022 7:56 pm

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

wriedmann · Post by **wriedmann** » Fri Sep 23, 2022 3:29 am

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

robert · Post by **robert** » Fri Sep 23, 2022 5:22 am

Nick,
What Wolfgang said.

Robert

NickFriend · Post by **NickFriend** » Fri Sep 23, 2022 8:19 am

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

wriedmann · Post by **wriedmann** » Fri Sep 23, 2022 8:33 am

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

NickFriend · Post by **NickFriend** » Fri Sep 23, 2022 8:52 am

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

ic2 · Post by **ic2** » Fri Sep 23, 2022 9:51 am

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

robert · Post by **robert** » Fri Sep 23, 2022 2:37 pm

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

Jamal · Post by **Jamal** » Fri Sep 23, 2022 6:58 pm

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

NickFriend · Post by **NickFriend** » Fri Sep 23, 2022 10:33 pm

Thanks for the info Robert, that's more or less what I suspected.

Nick

Main menu