I have several projects in PTC integrity 11.0 that I am currently using. I have to migrate all the projects from 11.0 to 11.2 with out losing the traceability, revision history, item relationship or project level ACL's and triggers. Please advise if there is any way to carry out this type of migration.
There is no direct way to get SI projects along with its history and versions and if you are talking about IM projects then history and all cant be migrated.
So if you want to migrate history and versions of SI projects then you need to raise PTC Integrity ticket
and provide below three files from the directory of the project that is being migrated:
Upgrading from 11.0 to 11.2 will not lose any data.
Obviously you should make sure you have a solid backup, just in case something bad happens.
Related
We are still running Magento community version 2.3.4x.
We are upgrading since 4 months to current version, there were many plug-ins not compatible and so on.
Now we are about 2-3 weeks before we can fully switch.
On 11. of Oct. Adobe released:
Security update available for Adobe Commerce | APSB22-48
https://helpx.adobe.com/security/products/magento/apsb22-48.html
But our version of out of service since one month.
So we can not switch now, and there is also no patch.
Adobe Commerce 2.4.5 and earlier versions
What can we do until then?
I know this is not an adequate question here, but since It will probably affect 60% of all Shop worldwide, it's necessary to ask this here.
Maybe try this: https://github.com/EmicoEcommerce/Magento-APSB22-48-Security-Patches
This repository contains Magento 2 Patch Files for the recently found security issues on 12-10-2022. The patch files aim to fix the CVE-2022-35698 and CVE-2022-35689 vulnerabilities.
I'm migrating from a HD to an SSD. I was using TortoiseSVN 1.7 on the HD for a project that has multiple coders using the same repository.
I installed TSVN 1.8 on the SSD, and am attempting to use it with the project's old-format working copy. It asks me to upgrade the format to 1.8, but I'm wondering if that permanent change is going to make its way back into the repository when I do my next checkin, and if that is going to cause problems for other coders not using the new format.
Thank you.
No. Internal local changes of WC structure doesn't reflected in remote repository: there are only a few compatibility issues between server- and client-side versions of SVN
LazyBadger is correct but a few more details are worth noting:
Be aware of the distinction of the SVN server vs the SVN client; TSVN is a client, existing separately on the machine of each developer. Thus, this question is addressing upgrading a client specifically.
When it asks you to upgrade the format to 1.8, it is talking about the infrastructure of your working copy, the way it stores and manages files on your box. That infrastructure is local to your machine; it is not reflected on the server.
However, it is not a general rule that you can always upgrade a client and remain compatible, but moving from TSVN 1.7 to TSVN 1.8 does, in fact, maintain compatibility.
Ultimately to answer this question each time you are considering an upgrade, have a look at the TortoiseSVN release notes--for 1.8 they are here. In there you will see that it specifically states that "Older clients and servers interoperate transparently with 1.8 servers and clients."
I would like to ask a question about wether or not I should do the migration to Liferay 6.2.
Me and my team are working since 4 month on a portal quite big developed with Liferay 6.1 (CE edition) and now, since the project publication date is still 4-5 month ahead (so I do have time), I was wondering if doing the migration to 6.2 now is a good choice.
I already tried the new version and I must say I am impressed about the new features and since now I haven't find any bugs.
Anyone had any experience on developing portlet/themes on Liferay 6.2? Is is worth it to do the migration now or shall I wait for the next ga2 release?
Any suggestion is very welcome.
Thanks
Depends mostly on the kind of work you've done on that portal. Even slight upgrades in Liferay, can have major differences in the source code. If this affects the work you've done, it will affect the upgrade too. For example, things will get difficult to update if :
You have developed custom portlets, as they will need recompilation for the new runtime
Developed Portlets that use ServiceBuilder might need more work than just a recompilation
Using Hooks (even simple jsp hooks) might need re-writing. ext hooks will almost certainly need to, and it can become a major pain
On, the other hand, if most of your work had to do with light theming and content management, it could become an relatively easy and painless upgrade.
In any case, make sure to keep a backup of your Liferay Database, because once you upgrade, there is no way to downgrade back to the initial version.
As you're using CE, my recommendation is to upgrade as soon as possible. Reason is that there are no more updates for 6.1, now that 6.2 is out. If you're going live in 5 months, you'd be on a version that's unsupported for half a year at the date of publication.
The alternative is to go to EE, which is supported for ~5 years from release, e.g. you'll have several years of support in front of you. However, as Liferay is paying my salary, note that I might be biased...
Of course, being unsupported "by Liferay" does not mean that you won't be able to fix any bugs or issues, but you'll have to do this on your own, and sooner or later you should upgrade anyway... If you're not yet live, I'm recommending to do it sooner.
Liferay 6.2 does not (yet) support as many marketplace apps as Liferay 6.1. Also Liferay 6.2 CE has bugs, and patches are available only to EE subscribers; this forced us to use Liferay 6.1 CE instead of 6.2 CE.
You will have issues if you are using the Vaadin framework under Liferay.
Liferay 6.2 CE does not support Vaadin out of the box ... it is delivered with Vaadin 6.8, but it is broken - your portlet code will break.
You would have to consider moving to Vaadin 7.1 at best ... and that is a non-trivial code migration as many items have been deprecated between 6.8 and 7.
I went that route and the learning curve was unexpectedly steep.
I have a project built around Subsonic 3.0.0.3 and have run into the dreaded medium trust issue, can anyone tell me is there a way I can mod the code myself to get this working or what the expected timescale for 3.1 version is? Its looking increasingly like I will have to ditch subsonic to get my system running
Regards
Mike
No timeframe for SubSonic 3.1 (or 3.0.0.4), but here are the current plans: http://groups.google.com/group/subsonicproject/browse_thread/thread/caae09418ce4d975/
The SubSonic Google discussion group is the best place to find out about the current development happenings for SubSonic.
Short answer, as soon as possible.
Long answer, there's a number of things planned for 3.1 these include (but are not necessarily limited to):
Oracle support
MediumTrust support
Automatic mapping of collections in SimpleRepository
These are all in development right now but before they become the main focus we need to get version 3.0.0.4 out the door with fixes for a lot of the outstanding issues listed on github. There's also a lot of more boring work going on behind the scenes which should make regular and stable releases easier.
The current release schedule is:
Version 3.0.0.4 - 22nd March 2010
Version 3.1 - 22nd May 2010
Does anyone use the MS SharePoint Solution Generator and VSeWSS 1.2 in a multi-developer environment with source safe? We are having issues re-deploying (because it doesn't really upgrade the solution with stsadm). It keeps saying the same feature is already installed - which it is, but it should retract the feature and re-install it - which it doesn't on some machines. Something is messed up with the feature's GUID but we can't find where that might be. One dev will be able to deploy and re-deploy but then the next dev won't. Where does VSeWSS 1.2 change the GUIDs? ARG!!!
We see the nice deployment targets (upgrade, etc) in STSDev but we're reluctant to use STSDev or the other codeplex tools because they are not supported by Microsoft. We have Visual Studio 2005 but not the money to upgrade to VS 2008 to get VSeWSS 1.3 - bummer.
---UPDATE----
I think we found a bug in VSeWSS that other's have commented on: Editing the projects properties resets some feature GUIDs.
It might also be a problem with the scope of the install. How do we get a site definition to install to the FARM scope in VSeWSS 1.2?
Don't worry too much about supported by Microsoft too much. While it is a consideration, the end result of MS SharePoint Solution Generator (terrible) and VSeWSS 1.2 are still SharePoint solutions and all solutions need to contain the same xml.
Could the deployment targets for STSDev be modified to work with your VSeWSS solution? After all, the deployment targets here are just working with STSAdm and a solution file.
In order to avoid the usual "works on my machine" you should set up a build and deployment system. If you are using virtual server or ESX server it should be fairly simply, and cheap as well. You should be able to use open source software all the way if you have more man power then money.
VSeWSS 1.2 and 1.3 store the feature GUID's in files in the /PKG directory of your Visual Studio solution. If you delete these files, or check our project into Source Control without these files and check them out on another machine, you will lose your GUIDs. Sure, VSeWSS will recreate the missing files for you, but it will do so with new GUIDs and new feature names.
A common requirement is to add the /PKG directory to your Visual Studio 2008 project and get it into source control.
You can read more about the files in the /PKG directory in the Release Notes for VSeWSS 1.3 here.
PS: We did some improvements to the Solution Generator in VSeWSS 1.3, but it wont generate a 100% perfect solution for you.