I got an Odoo 15 Enterprise running with the Odoo.sh platform.
When I add an OCA repository, I add it with the Submodule option, and this generates a OCA directory inside src/user. Which is the best way to update that code? If I go to src/user/OCA/repository-name, would doing a git pull there be ok?
Can anyone share their method? There is documentation on how to create your own modules, but not much about adding external repos and keep them updated.
Related
We've been using the NestJS to build the backend service(=original project from now on). We're also going to create another NestJS application which is depending on same database with the original one so I need to access the entities(typeorm's entities) in original project. What's the best way of the sharing the entities(or modules) between multiple NestJS applications? Some ways I've thought are
creating entity files which might looks same with the one in original applications. (copy and paste)
creating module(need to be shared) as a npm package and install it in new project.
=> I feel like it's quite overkill as I need to create account and pay to npm for making private npm modules.
Any ideas or suggestion? Thanks in advance!
The optimal effort/result solution may be a monorepo. The idea is to create a nestJS project of type library which can hold assets you want to share. Other instances can import assets/interfaces/classes very easly from there.
If you go further than that into monorepos, tools like Nx are also an option but also require more time to set up.
Copy/paste would be a maintenance nightmare in my opinion and manual library/dependency share is pretty much the same effort if not more as using provided solutions like monorepo pattern.
We need to migrate our VSTS team project. I already saw that this is an eagerly awaited feature from the Visual Studio user Voice.
However, in our case the new team project is to be in the same VSTS account. Is there a way to do this while also keeping version control change history? Keeping the change history available as part of the old team project is unfortunately not an option as we will lose access to the old team project soon after migration.
If somebody has done this before with the help of any of the below tools, then it would be great if they can share their experience:
VSTS copy project
VSTS sync migrator
OpsHub
It's a bit unclear what you're about to migrate from where. And why you'd lose access to the existing project. And you have different options based on the current source control type selected.
One option which you could try is to create 2 new accounts and leave the whole old account in read-only state. That should leave the history available to everyone. You can then spin up as many new accounts as you want, using just the latest version of the sources.
Git
If it's a Git repository it's as simple as making a local clone of the whole repo, creating a new team project in VSTS and pushing the clone into its second home.
TFVC
If it's TFVC, it's much harder. I've used OpsHub in the past which works reasonably well, but in our case completely got stuck in a couple of strange merge situations. Those were probably created as part of work done back when that team project was hosted in TFS 2008, so you may be luckier than we were.
You could decide to move to Git as part of your migration. Use git-tfs to create a local git repository with all your TFVC history and then push that into a bare Git repository in your new team project. Or use the TFVC import tool. There's quite a bit of documentation on this subject.
The VSTS Sync Migrator supports a snapshot without history as far as I can tell. Which would not suit you.
VSTS Copy Project doesn't support TFVC, and is no option in this case.
An option that's missing from your list is Timely Migration, it supports TFVC to TFVC migrations among other options. I've used them a long time ago to copy data between TFS servers. Back then they were working exactly as advertised.
I want virtocommerce in my own local repository.
storefront is a solution that will configure it according to the following link:
Storefront Source Code Getting Started
And it works.
But I want to have a solution For platforms and modules,
Like the link below:
vc-integrations
But I need the platform and modules to be connected to the github for the latest changes.
I've studied the link below:
Source Code Getting Started
but I do not understand how should I configure for my goals (one solution for platfrom and modules and fork, clone ,upstream for all for get latest versions of them)
We've used to have a single repository and single solution for Virto Commerce Manager and modules (vc-integrations). It was difficult to maintain and release often. That's why the single repository was split into many "1 module per repository" pieces.
We consider that in most cases having only Virto Commerce Manager configured should be sufficient. What's your scenario? Check "Manual module installation from source code" section in Source Code Getting Started to get started.
Any suggestions of how to structure my solutions when developing custom Modules and frontend?
I.e. Should I just clone the repoy and add my modules and change web.config with transform files directly in the repo. Will a future pull working well then? any ideas for simple developing and simple upgrade?
Or is it wrong aproach. Should i use azure deploy script/ slot settings and call virto api to add virto modules...
ok i saw thar virto has updated its documentation
http://docs.virtocommerce.com/display/vc2devguide/Developing+a+custom+solution
can anyone give an detailed procedure on how to
migrate projects from gforge version(4.5) to teamforge version 5.2.0.
Migration includes source repository, bug tracking, wiki and discussions.
is it possible to shift all of them.
What's the best way to handle a situation like this?
Thank
You
Teamforge uses Subversion, so assuming you have commandline access to the server then you can use the svnadmin dump and svnadmin load commands.
You will need to run these commands for each repository.
Some (I don't know which) of the pages and wiki are also stored in subversion repositories, so you may be able to migrate that using the same method.