玛根托；私有/公共文件系统层
我想将 magento 包拆分到私有和公共 Web 目录中。例如，私有目录可在多个项目上重用，它只是应用程序。
- 私人/
- 应用程序、下载器、包含、lib、pkginfo、var
- public/
- 404、js、media、report、skin + 当前根文件（index.php 等）
我在 SVN 中进行设置，其中只需一份 magento 就可以处理不同阶段的各种项目。
我列出了我的第一个目标；
- 包含所有可重用包部分的私有目录
- 只包含本地核心代码、包扩展、皮肤和 API 实现的公共目录
- 显着缩小工作副本的大小
- 对于 db 来说，我计划使用一段本地代码来修复基本 url
- 单独的 Zend Framework 和其他潜在库
- 这些应该指向全局现有库目录（Zend 已经在这里;-)）
- 保持 magento 的供应商源是最新的
- 软件包被标记为未受影响，以确保正确更新
我不确定如何在 SVN 中设置从供应商源到单独目录的流程。
I want to split up the magento package in a private and public web directory. E.g. the private directory is reuseable on multiple projects, its just the app.
- private/
- app, downloader, includes, lib, pkginfo, var
- public/
- 404, js, media, report, skin + current root files (index.php etc.)
Im setting this up in SVN where just one copy of magento can handle various projects on different stages.
I've listed my first goals;
- Private directory containing all the reuseable package parts
- Public directory containing just local core code, package extensions, skins and API implementations
- Downsizes working copies significantly
- For db's im planning to use a piece of local code fixing the base url
- Separate Zend Framework and other potential libraries
- These should point to a global existing library directory (Zend is already here ;-))
- Keeping magento's vendor source up2date
- Packages are tagged untouched to ensure a proper update
Im not sure how to set up the flow in SVN from vendor source to separated directories.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您需要对设置方式进行一些修改：
此设置也不允许安装扩展，扩展可以将文件放置在 Magento 树中的任何位置，包括应用程序和库。尤其是应用程序目录几乎总是需要在 etc/ 和 code/ 中进行自定义。
我认为这需要大量的设置和维护工作，但这无疑是一个有趣的练习，如果用作标准部署脚本的一部分，可能有助于更快的部署。
There's a few modifications you'll need to make to the way you've set things up:
This setup also doesn't easily allow for installing extensions, which can place files anywhere in the Magento tree, including app and lib. The app directory in particular will almost always require customisations in etc/ and code/.
I think this would be a lot of work to set up and maintain but it's certainly an interesting exercise and may help with faster deployments if used as part of a standard deployment script.