Difference between revisions of "Creating A Patch/ru"

From Free Pascal wiki
Jump to navigationJump to search
Line 54: Line 54:
 
Рекомендуемый способ отправки патча - через [http://bugs.freepascal.org bug tracker], подробности см. [[How_do_I_create_a_bug_report/ru|Как создать отчет об ошибке]]. Если есть отчет о проблеме, исправляемой вашим патчем, используйте ее, в противном случае создайте новую проблему. Загрузите файл, чтобы прикрепить его к проблеме.
 
Рекомендуемый способ отправки патча - через [http://bugs.freepascal.org bug tracker], подробности см. [[How_do_I_create_a_bug_report/ru|Как создать отчет об ошибке]]. Если есть отчет о проблеме, исправляемой вашим патчем, используйте ее, в противном случае создайте новую проблему. Загрузите файл, чтобы прикрепить его к проблеме.
  
==Using a forked Git repository directly==
+
==Использование веток Git-репозитория напрямую==
It is possible to use Git in a distributed manner also for Lazarus development.
+
Можно использовать Git распределенным образом и для разработки Lazarus.
At least developers JuhaManninen and Alexander Klenin ("Ask") are ready to accept code in a Git repository.
+
По крайней мере, разработчики JuhaManninen и Alexander Klenin ("Ask") готовы принимать код в Git-репозитории.
  
In practice the repository must be forked from the Lazarus mirror in GitHub.
+
На практике хранилище должно быть разветвлено из зеркала Lazarus в GitHub.
The code must be in a separate branch and rebased against "upstream" branch.
+
Код должен быть в отдельной ветке и перебазирован от ветки "upstream".
This is not tested yet, we can add more details here when somebody actually forks the repo and creates code.
+
Это еще не проверено, мы можем добавить больше деталей, когда кто-то на самом деле ответвится от репо и создаст код.
  
The limitation of this model is that the code must belong to the area of expertise of the developers working with Git.
+
Ограничением этой модели является то, что код должен принадлежать к области компетенции разработчиков, работающих с Git.
If the code is outside that area, you can still use Git but you must create patches and send them to bug tracker.
+
Если код находится за пределами этой области, вы все равно можете использовать Git, но вы должны создавать патчи и отправлять их в bug tracker.
  
 
==Applying a patch==
 
==Applying a patch==

Revision as of 16:07, 30 August 2019

Deutsch (de) English (en) español (es) français (fr) 日本語 (ja) português (pt) русский (ru) slovenčina (sk)

Если вы хотите отправить улучшения в код FPC или Lazarus, вам нужно отправить патч, который разработчики могут легко слить с исходным кодом.

Исключения:

  1. файлы перевода .po следует отправлять как целые файлы
  2. новые файлы должны быть отправлены как целые файлы с указанием места их размещения

Требования

Вам нужны версии Lazarus (или FPC) trunk/для разработки. Вы можете получить Lazarus(и FPC), используя SVN или Git.

Warning-icon.png

Предупреждение: Если вы отправляете исправления, не создавайте их на основе стабильных версиий Lazarus/FPC. Обычно версия для разработки сильно отличается от стабильной версии, так как разработчики применили множество улучшений и исправлений.

Отличия платформы

В инструкциях ниже предполагается, что вы открыли командную строку и переместились (команда cd) в каталог хранилища. Вот подробности:

Windows

Предполагая, что вы извлекли Lazarus в C:\lazarus, откройте командную строку (cmd.exe) и введите «cd \lazarus».

*nix systems

Предполагая, что вы извлекли Lazarus в ~/lazarus, откройте терминал и наберите "cd ~/lazarus".

Создание патча с использованием SVN

svn diff > mypatch.diff

Это включает в себя все измененные файлы во всем хранилище SVN.

Вы также можете определить отдельные файлы, чтобы убедиться, что туда не попал мусор, например. :

svn diff ide/main.pp ideintf/objectinspector.pp > mypatch.diff
Light bulb  Примечание: Если вы используете TortoiseSVN в Windows, вы можете выбрать папку, в которую Lazarus был извлечен в Windows Explorer, а затем щелкнуть правой кнопкой мыши, чтобы выбрать TortoiseSVN-> Create Patch(Создать патч) ...

См.также Разрешение проблем, если у вас имеются проблемы .

Создание патча с помощью Git

Во-первых, разрабатывайте свой код в отдельной ветке!

Пока ваша ветка разработки активна, вы можете создавать патчи всех ваших локальных коммитов:

git format-patch master

Это создает набор исправлений с именами, такими как "0001-CommitMsg.patch", "0002-CommitMsg.patch" и так далее.

Если вы хотите, чтобы все изменения были внесены в один патч, либо объедините коммиты, используя "git rebase -i ...", либо используйте следующую команду:

git format-patch master --stdout > mypatch.patch

Light bulb  Примечание: ветка "master" при использовании ссылки git-svn следует за транком SVN по умолчанию. Однако зеркальный репозиторий в GitHub вместо этого использует ветку "upstream".

Тогда вы должны заменить "master" на "upstream" в выше приведенных командах.

Отправка патча

Теперь у вас есть патч. Я бы посоветовал еще раз просмотреть файл, чтобы убедиться, что он выглядит нормально (без неожиданных изменений).

Рекомендуемый способ отправки патча - через bug tracker, подробности см. Как создать отчет об ошибке. Если есть отчет о проблеме, исправляемой вашим патчем, используйте ее, в противном случае создайте новую проблему. Загрузите файл, чтобы прикрепить его к проблеме.

Использование веток Git-репозитория напрямую

Можно использовать Git распределенным образом и для разработки Lazarus. По крайней мере, разработчики JuhaManninen и Alexander Klenin ("Ask") готовы принимать код в Git-репозитории.

На практике хранилище должно быть разветвлено из зеркала Lazarus в GitHub. Код должен быть в отдельной ветке и перебазирован от ветки "upstream". Это еще не проверено, мы можем добавить больше деталей, когда кто-то на самом деле ответвится от репо и создаст код.

Ограничением этой модели является то, что код должен принадлежать к области компетенции разработчиков, работающих с Git. Если код находится за пределами этой области, вы все равно можете использовать Git, но вы должны создавать патчи и отправлять их в bug tracker.

Applying a patch

This explains how to apply somebody else's patch to your local repository. You can test the patch by using the --dry-run toggle switch like this:

patch --dry-run < somepatch.diff

The output of the patch program will be identical to the actual patching, only it does not alter the sourcecode files. Very handy for testing, without the possibility to screw up your source.

A patch made with "svn diff"

To do the final patching, use the following commandline:

patch < somepatch.diff

If that doesn't work because the path layout of your environment is different from the environment where the patch was created, you can tell patch to strip out all path information:

patch -p0 < somepatch.diff

Any GUI tool for diffs on Windows can handle these patches, too, including TortoiseMerge.

A patch made with "git format-patch"

Git

Git itself applies the patch like this :

git apply 0001-gitpatch.patch

patch

The "patch" command now supports git format patches with -p1. This is tested with patch v.2.6.1 on Linux, old versions may not support it.

patch -p1 < 0001-gitpatch.patch

"patch" is available for Windows, too, but there are also GUI tools for the job.

TortoiseMerge

TortoiseMerge supports the Git format patch without problems. It is installed together with Tortoise SVN but is not integrated in explorer. It must be opened from the Start menu.

ToDo: add more GUI tools that support Git format patches

Troubleshooting

Finally, patches may have a Unix/Linux line ending (LF) while your local file has Windows (CR+LF) line endings or vice versa. You'll have to convert the patch file before applying on Windows at least, as the supplied patch.exe is picky about line endings.

On Windows, the patch.exe supplied with FPC/Lazarus is very picky; you may have better luck with the patch.exe supplied by Git:

"C:\Program Files (x86)\Git\bin\patch.exe" -p0 < mypatch.diff

... or the svn patch command available since SVN 1.7.

See also