Использование Subversion [закрыто]

Я предлагаю регистрироваться рано и часто.

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

Если вы еще не сделали этого, проверьте Красную книгу, это отличный ресурс для информации svn.

При создании нового проекта с нуля я обычно делаю это в пользовательской области в SVN, такой как

/svn/users/me/project1

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

/svn/project1/trunk

Использование ветвей требует немного дополнительной работы, поэтому мы не используем их без необходимости. То есть, когда над проектом работают несколько человек. один и тот же проект и коллизии часто или я работаю над функцией, которую я мог бы решить вернуть и выбросить. Если это сделано в ветке, я могу просто выбрать не сливать, а просто удалить ее.

Все ответы предполагают, что вы регистрируетесь рано, часто, я не могу согласиться больше. Вот и все, что я скажу по этому поводу. Тем не менее, я прочитал резюме как: какие виды использования могут соответствовать Subversion? Вот вам и ответ на этот вопрос.

Я читал о компаниях, использующих Subversion в качестве хранилища приложений. Итак, они сообщают серверу, что хотят установить версию X приложения Y. Затем сервер запускает обновление на сервере SVN. И они также хранили там конфигурационные файлы. И любые изменения, внесенные в конфигурацию (через отдельный веб-интерфейс для конечных пользователей), затем фиксировались в репозитории SVN config. Это блестяще. Конечно, эти ребята использовали MS Power Shell на Win2k3, но все же эту технику можно применить и в других местах.

Регистрируйтесь немедленно, не раньше. Даже если у вас нет ничего, кроме специального текстового файла, содержащего мозговые штурмы и какой-то ужасно загадочный код psuedo, зафиксируйте его.

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

Если у вас в багажнике есть нулевой код, я, скорее всего, забуду о вас. Если у вас есть по крайней мере какой-то файл, объясняющий ваш предполагаемый дизайн и некоторый код psuedo, я, вероятно, начну посылать вам патчи, которые показывают мои идеи.

Проект с пустым репозиторием кричит "зуд, который никогда не будет поцарапан".. так что нажми на что-нибудь как можно скорее.

После этого совершайте частые коммиты. Я люблю делать много небольших, упорядоченных обязательств, поэтому легко отслеживать регрессии и откатывать/исправлять токсичные изменения.

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

2. Нет закона, требующего, чтобы первоначальная регистрация заезда происходила в отеле. Ствол или ветка. Вы можете запустить магистраль с пустым проектом, чтобы он был стабильным с самого начала, а затем разветвиться, чтобы выполнить разработку и объединить его обратно в магистраль после завершения. Вы также можете выбрать возврат пустого проекта в ветвь и разработать первую рабочую или базовую функцию, прежде чем объединять что-то существенное в магистраль. В любом случае, исходя из пункта 1, ствол должен быть стабильным и высококачественным. Только объединяйте высококачественный контент в Багажник.

3. Опять же, нет строгого мандата на этот тип практики. Некоторые команды разветвляют все, даже простой рефакторинг изменений имен переменных. Некоторые команды даже не знают ветвления / слияния и развивают все в одной ветке (стволе). У каждой команды есть свой уровень сбалансированности в этом вопросе. Мое личное руководство заключается в том, что если будут новые функции или серьезные исправления ошибок или перепроектирование, разветвляйте их для тестирования. Если это незначительное исправление, как написание строки ошибки или отображение четырех знаков после запятой вместо двух на веб-странице, исправление копии магистрали должно быть достаточным. Конечно, интерпретации "основного "и" второстепенного " будут отличаться, поэтому ведущие разработки/команды должны установить свои стандарты. В любом случае, должны бытьмодульные/интеграционные тесты, сопровождающие изменения , чтобы проверить, что ветвь или ствол работают так, как задумано, как можно более бездефектно. Ключевое слово, которое нужно запомнить, всегда "высокое качество, проверено код".