| Summary: | Wine-tests: разрешение конфликта в файле VERSION | ||
|---|---|---|---|
| Product: | [Свободные проекты (Open source projects)] WINE-tests | Reporter: | Виталий Перов <vitperov> |
| Component: | Общее | Assignee: | Виталий Перов <vitperov> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | minor | ||
| Priority: | P4 | CC: | amorozov, baraka, lav |
| Version: | не указана | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | All | ||
| Whiteboard: | |||
| Заявки RT: | Связано с: | ||
| Дата напоминания: | |||
| Bug Depends on: | 6272 | ||
| Bug Blocks: | 6264 | ||
|
Description
Виталий Перов
2011-08-15 13:11:36 MSK
> 2) выполнить autoconf -f
Я бы предложил такую последовательность:
tools/make_requests
autoheader
autoconf
> tools/make_requests
Но с этой штукой есть одна сложность. Она вроде бы всегда обновляет версию в include/wine/server_protocol.h, даже если ничего не изменилось. Поэтому в идеале было бы неплохо если поменялась только версия, то откатывать это изменение назад.
(В ответ на comment #2) > > tools/make_requests > Но с этой штукой есть одна сложность. Она вроде бы всегда обновляет версию в > include/wine/server_protocol.h, даже если ничего не изменилось. Поэтому в > идеале было бы неплохо если поменялась только версия, то откатывать это > изменение назад. Можно добавить отдельное правило для разрешения конфликта в include/wine/server_protocol.h. Т.е если есть конфликт в этом файле, то вызывать tools/make_requests. Причём, если я правильно понимаю, делать это нужно в самом конце, когда уже разрешены конфликты в остальных файлах. Да, лучше вызывать после правки всего, что не генерируется автоматически. Тут ещё о таком моменте я что-то сразу не подумал: если будут конфликты в include/wine/server_protocol.h, то скорее всего будут и конфликты в server/protocol.def, т.е., видимо, надо либо научиться автоматически править конфликты в protocol.def, либо тогда нет особого смысла запускать tools/make_requests. (В ответ на comment #4) > Да, лучше вызывать после правки всего, что не генерируется автоматически. Тут > ещё о таком моменте я что-то сразу не подумал: если будут конфликты в > include/wine/server_protocol.h, то скорее всего будут и конфликты в > server/protocol.def, т.е., видимо, надо либо научиться автоматически править > конфликты в protocol.def, либо тогда нет особого смысла запускать > tools/make_requests. Я часто встречал, что конфликты только в include/wine/server_protocol.h. Притом конфликты связано только со строкой версии. И чтобы при этом были конфликты в server/protocol.def - такое бывает очень редко > Я часто встречал, что конфликты только в include/wine/server_protocol.h. Притом
> конфликты связано только со строкой версии.
> И чтобы при этом были конфликты в server/protocol.def - такое бывает очень
> редко
Не знаю, подойдёт ли в таком случае tools/make_requests. Она версию просто на единицу увеличивает. А если в этой строке конфликт, то не знаю, как она себя поведёт. Тут лучше проверить.
(В ответ на comment #6) > Не знаю, подойдёт ли в таком случае tools/make_requests. Она версию просто на > единицу увеличивает. А если в этой строке конфликт, то не знаю, как она себя > поведёт. Тут лучше проверить. Создал отдельную багу #7539. (В ответ на comment #1) > > 2) выполнить autoconf -f > Я бы предложил такую последовательность: > tools/make_requests > autoheader > autoconf Только вот не совсем понимаю зачем вызывать autoheader? > Только вот не совсем понимаю зачем вызывать autoheader?
Оно обновляет include/config.h.in при изменении configure.ac
Сделал отдельный метод resolve_conflict_in() для разрешения конфликтов в специальных файлах. В классе git_repository этот метод разрешает конфликты никак не связаннаые с wine. Например в configure. В классе wine_repository метод разрешает конфликты связанные с wine Реализовал исправления конфликта в файле 'VERSION' По счастливой случайности он оказался раньше, чем 'configure' (надеюсь так будет каждый раз', поэтому конфликт в configure затем сам исправится. Ещё нужно разобраться со spec-файлами, и изменять версию там. (В ответ на comment #11) > Ещё нужно разобраться со spec-файлами, и изменять версию там. Реализовал обновление полей Version и Reliase в спеке. Осталось добавить Changelog (В ответ на comment #12) > Осталось добавить Changelog Changelog добавляется. Осталось только всё проверить на реальном репозитории. Проверил. Изменил конфигурацию для builder-robot. Всё работает! |