Лучший способ предотвратить изменения в ветке с помощью Subversion

Мы используем Subversion для работы над основной веткой, функциональными ветками для важных функций (работа> 1 дня) и релизными ветками.

Мы удаляем функциональные ветки после того, как они успешно объединены, но мы хотим оставить релизные ветки на тот случай, если они понадобятся для исправления ошибок и так далее.

Каждый из нас проверяет как минимум корень проекта, чтобы у всех нас была копия всей структуры каталогов (ствол, ветки, выпуски). Насколько я могу научить людей проверять, работают ли они с основной веткой, они могут случайно работать с веткой выпуска.

Как лучше всего этого не допустить? Я подумываю заблокировать все файлы в ветке выпуска, поможет ли это? Какие еще есть варианты?


branch svn
person Garry Shutler    schedule 22.04.2009    source источник

Ответы (5)


arrow_upward
6
arrow_downward

Почему у всех проверяется вся иерархия SVN? Было бы намного меньше подверженности ошибкам, если бы каждый проверил только ствол / ветки, над которыми они работают. Вы не можете проверить что-то в ветке, которую не проверяли.

Я могу дополнить практику пометить выпуск, как указано в Раззи.

person boutta    schedule 22.04.2009

arrow_upward
5
arrow_downward

Я не знаю ни одного встроенного способа активно предотвратить это. Вероятно, вы могли бы сделать это, используя «предварительную привязку репозитория». Это небольшая программа, которая запускается перед каждой фиксацией. Если это не удается, фиксация в целом терпит неудачу. См. главу о хуках в книге о Subversion.

Ваш сценарий ловушки будет проверять путь, который будет зафиксирован, и запрещать некоторые из них. Это может помочь: http://metacpan.org/pod/SVN::Hooks

Тем не менее, вы действительно уверены, что хотите это сделать?

Мы также используем ветки выпуска, и мы делаем время от времени проверяем в них что-то, обычно это критические исправления для клиентов, которые не могут сразу перейти на последнюю версию. Вы уверены, что вам это никогда не понадобится?

person sleske    schedule 22.04.2009
comment
Некоторые примеры отказа от хуков предварительной фиксации: stackoverflow.com/questions/464384/ - person Vadzim; 10.09.2017

arrow_upward
3
arrow_downward

Не тратьте время зря, пытаясь этого не допустить. Если разработчик вносит изменение не в ту ветку, просто отмените его, если это произойдет, и обязательно сообщите об этом разработчику.

... hack hack hack ... on branch
$ svn ci -m "Feature-1337 implemented" branch
Revision 12345

...oops...

$ svn merge -c12345 branch trunk
$ svn ci -m "moved Feature-1337 from branch to trunk" trunk
$ svn merge -c-12345 branch branch
$ svn ci -m "reverted Feature-1337 on branch. it's intended only for trunk" branch
person bendin    schedule 22.04.2009
comment
Итак, чтобы предотвратить потерю работы, я бы записал ревизию, слился с веткой из ствола, слился обратно с стволом, чтобы уловить изменения, сделанные в ветке, а затем вернуть папку ветки обратно к предыдущей ревизии? - person Garry Shutler; 22.04.2009
comment
Затем злобно избил разработчика, который заставил меня делать всю эту работу :) - person Garry Shutler; 22.04.2009
comment
Да, объедините функцию branch- ›trunk, если это не дерьмо и принадлежит транку. Затем выполните обратное слияние на ветке, чтобы откатить ее туда. Не забудьте проверить изменения. Затем примените подсказку по четыре. - person bendin; 22.04.2009

arrow_upward
3
arrow_downward

Я думаю, что было бы хорошей практикой удалить «ветки выпуска» и вместо этого сделать их тегом, поскольку это цель тега.

На самом деле это не решает проблему, хотя может предотвратить большее количество таких несчастных случаев, поскольку вы никогда не должны работать с тегом. И я согласен с брендом, если это все еще произойдет, отмените эти изменения и выгните разработчика :-)

person Razzie    schedule 22.04.2009

arrow_upward
3
arrow_downward

Почему вы используете ветки в качестве тегов? Я бы посоветовал:

  1. Стандарты местного развития (т. Е. Не делайте обязательств там, где мы просим вас не брать на себя обязательства)
  2. Повышение квалификации по Subversion (т.е. почему разработчики проверяют репозиторий целиком?)
  3. Используйте структуру тегов по назначению

При этом предполагается, что иерархия вашего репозитория представлена ​​следующим образом:

* repo
  - tags
  - trunk
  - branches

Хотя книга SVN выступает против детального контроля таким образом, вы также можете использовать svn_access_file, чтобы предотвратить коммиты чего-либо в ветвях? Например:

[repo:/]
@developers = rw

[repo:/branches]
@developers = r
@rel_engineers = rw

Если вы хотите, чтобы разработчики могли создавать ветки, вам придется спускаться в каждую ветвь индивидуально (что возвращает нас к исходной посылке книги SVN, в которой в первую очередь советуют не использовать этот метод).

person Gary Chambers    schedule 07.05.2009