Использование мерзавца в компании?

@nssmart,

Да, отметьте раздел документа Word с переменной, такой как {value1}, а затем, если вы загрузили PHPWORD, вы можете заменить этот раздел с помощью кода

$PHPWord = new PHPWord();

$document = $PHPWord->loadTemplate(Doc location);

$document->setValue('value1', 'Description');

Это также можно использовать для заполнения данных в таблицах.

14
задан martinus 31 December 2008 в 11:28
поделиться

2 ответа

Структура: Да, 1 проект на репозиторий. Мерзавец разработан, чтобы это проложило себе путь, и это делает это вполне приятно.

Код Многократного использования: Использование подмодули мерзавца (очень похожий на svn:externals, только лучше)

Права доступа: Да, управление доступом часто создается вокруг ssh и открытых ключей. Если Вы хотите разместить его сами, попробуйте gitosis, но я на самом деле настоятельно рекомендую размещенное решение, как GitHub.

16
ответ дан 1 December 2019 в 13:48
поделиться

I would use a single git repo, if you don't need to restrict read access.

Structure: filesystem hierarchy

Reusing code: trough the build system

Access rights: write access is patch merging. It can be controlled by script or best, by a designed person. If you have like 3 projects, each has a project manager who is responsible for merging code in the main branch. Remember, this is how linux works and git is especially well tailored for that scenario.

Why use a single repo ?

The main reason is regarding code divergence. Let's say you have that 3 projects and some shared libraries. Team A needs to adapt libXY's interface and commits the code, with two scenarios:

  1. Submodules: Team B and C will then have to update their submodule and report to Team A if the changes broke their code. They can also update the code themselves, but then Team A might also have some code breakage.

  2. One-big-repo: Team A changes the code until all tests pass. Changes gets merged upstream and everybody is happy.

Running all tests in scenario one is also possible, but then, it's the same as if you have one repo since you had to checkout all code.

This is my point of view. Maybe you have some big assets in a repo you don't want everybody to checkout because they take like 2GB. Maybe your code base is so big that the overhea doesn't matter.

But I believe that unless you are Google, IBM, ... the overhead you'll pay to manage multiple repos will be too big and make you loose time you could have spend on more productive things.

Cheers, zimbatm

1
ответ дан 1 December 2019 в 13:48
поделиться