Аргументы против zip-файлов как [закрытое] управление исходным кодом

Лучший аргумент, несомненно, заключается в том, что использование системы контроля версий, такой как Subversion или Mercurial, намного проще и безопаснее, чем возиться о с zip файлами. Я сомневаюсь, что на эту тему было написано много статей, поскольку использование zip-файлы для этой цели совершенно очевидно неверны.

Существует ряд SO-вопросов об общих преимуществах контроля версий. Например, Как я могу убедить свой отдел внедрить систему контроля версий? и https://stackoverflow.com/questions/250984/do-i-really-need-version-control

• Создание и управление zip-файлами подвержено ошибкам.
• Реальный контроль версий дает вам инструменты для понимания вашего кода:
  • Просмотр истории
  • Различия между ревизиями
  • Аннотации исходных файлов для отслеживания происхождения изменения
• Реальный контроль исходного кода несложен, здесь много помощи.

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

Я добавлю кое-что, что поможет вам в вашей битве: ВАША КОМПАНИЯ @ $ #% & $ # @ СУМАСШЕДШАЯ !!! ZIP-ФАЙЛЫ ??? ARE YOU @ # $ # @% KIDDING ME ???

Я предполагаю, что этот вопрос был задан, потому что исходный плакат работает в офисе, где стандартной практикой является обмен zip-файлами.

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

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

Zip-файлы работают как очень простая форма контроля версий. . Это способ разделить «состояния» источника. Однако это не хорошая форма контроля версий, потому что вам нужно проделать много работы для выполнения основных задач управления исходным кодом. Например:

1. Команда Боба работает над важной функцией, которая требует изменения десятков файлов. Некоторое время он работает на своей частной территории, контролируемой почтовым индексом. Он создал 30 новых файлов, добавил функции к 12 существующим файлам и внес изменения в существующее поведение в 3 существующих файлах за 4 месяца. Как объединить Боба? s работа с основным стволом, которая также развивалась за последние 4 месяца? Вы вручную сравниваете тысячи строк кода и решаете, как их объединить? Как вы гарантируете, что все, что использует 15 существующих файлов, не сломано? Как вы гарантируете, что функции Боба или основные функции ствола случайно не пропущены?
2. Алиса исследует ошибку в своем коде и понимает, что один из классов Сэма изменил свое поведение. Сэм говорит, что он не менял. Как Алиса узнает, когда и почему было внесено изменение? Как Алиса узнает, кто зависит от изменения?
3. Крупный заказчик сообщил об ошибке в более старой версии программы. Этому клиенту нужно исправление, и он достаточно важен, чтобы требовать исправления. Как добавить код в старый zip-файл таким образом, чтобы он присутствовал и в новых файлах? Также, Как записать, что между двумя изменениями существует связь?

Это всего лишь три сценария, с которыми хорошо справляется система контроля версий. Ситуация 1 обрабатывается ветвями развития. Почти каждая система контроля версий имеет понятие ветвей, которые можно разрабатывать параллельно и при необходимости объединять. Ситуация 2 легко разрешается любой системой управления версиями с функцией «обвинения» и менее легко решается простым поиском в журналах фиксации. Ситуация 3 - это вариант ситуации 1, но когда вы объединяете ветки, большинство систем контроля версий делают заметку. Например, вы должны создать ветвь от старой версии, исправить ошибку, а затем объединить эту ветвь с новым кодом. Теперь, когда кто-то спрашивает: «Откуда это изменение?» они видят, что он был объединен из ветки патча, и изменение было внесено для исправления ошибки.

Между прочим, я был в каждой из этих трех ситуаций и использовал как SVN, так и Perforce; оба сделали поиск решения очень простым.

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

These people already know all the arguments for SCM, there is nothing anyone can say to them that will sell them on it. These things must happen:

1. You install SCM on your local machine and use it. If you must, have it autogenerate these .zip files at every build, so no one outside your cube knows the difference.

2. Some kind of disaster occurs, like loss of work, show-stopper bug is re-introduced or some other worst-case scenario that is the real reason we all use SCM (the other features we learn to appreciate later).

3. You are unaffected by the disaster, and/or use your personal copy of the code in SCM to fix the problem/recover the lost work/whatever.

4. You are a hero and everyone wants to know how you did it.

Only by experiencing firsthand the pain of loss caused by poor SCM practices will your organization realize the benefits of SCM. You're smart enough to learn from the mistakes of others, but not everyone is. The rest of the time, you'll just be 2/3X more productive than the rest of the team and maybe, just maybe they'll wonder how.

By the way, this is how you get agile, continuous integration, unit testing, etc into the organization: lead by example.

The ZIP solution requires a pro-active step at the end of the development cycle when things tend to get dropped because no one outside the dev group notices when they doesn't happen. Sort of like that final code cleanup you always plan on doing when things slow down.

An SCM integrated into the dev environment pretty much enforces/encourages keeping a version history with a small amount of effort all the way through the process. This makes it more likely that a version history will actually be created.

On Using ZIP as a SCM
I'm not going to take as hard of a line as some of the others on the ZIP file solution. It is at least better than nothing. It is a perfectly valid way of keeping version histories, it is just a lot more labor intensive, error prone, and lacks a lot of useful features.

Know who you are selling to

Someone in the Dev Group: Focus your arguments on features like ease of troubleshooting by using change histories, safety to experiment with big code changes (because of rollback), and avoiding accidents where work is overwritten by other developers.

Non-Tech Managers/Bean-counters: There are free/low-cost tools that will reduce the labor cost of version control and give greater accountability/transparency into what each developer is doing/the source of coding mostakes.

Это нехорошо, так как создание zip-архива перед выпуском означает потерю значительных возможностей, которые дает контроль версий.

Обычно вам следует зарегистрироваться в репозитории после того, как вы добавили / удалили / изменили функциональный аспект. Чтобы вы могли вернуться позже, когда возникнет ошибка, которая, по вашему мнению, возникла из-за этого изменения. Или когда вы говорите «черт возьми, это работало до того, как формат файла изменился когда-нибудь в марте». Называя ревизии после изменений, их легче запомнить, потому что вы забыли, что было сделано 27 марта 2009 г.

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

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

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

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

Я давно написал инструмент контроля версий для компании, которая занималась созданием заголовков DVD. Раньше у них не было ничего, только каталог, полный клипов, значков, сценариев и т. Д., Который можно было взломать, и не было возможности вернуться, если что-то пошло не так и т. Д. ОДНАКО эти люди были «художниками», а не программистами, поэтому они могли не (не могли бы ???!) научиться пользоваться приличной системой контроля версий. Итак, в качестве минимального инструмента, позволяющего избавиться от грязи, я написал утилиту, которая заархивировала текущее состояние каталога, присвоила Zip значимое имя (дата + комментарий, предоставленный пользователем) и вставила его в каталог резервных копий, а также позволил вам восстановить одну из этих резервных копий.

Таким образом, zip-архивы МОГУТ обеспечивать минимальный уровень контроля версий, и я говорю как человек, который поддерживал этот подход, когда он был подходящим для уровня навыков (с точки зрения программирования, я не хочу иметь в виду, что они не могли манипулировать пикселями!) людей, использующих его.

Но Как программист, вы должны подумать о том, чтобы использовать инструмент, который действительно вам поможет. Таким образом, вы хотите иметь возможность сравнивать различия для отдельных файлов, сравнивать различия между полными наборами этапов и (если вы работаете над чем-то другим, кроме тривиальных программ) обрабатывать ветвление и слияние. Если вам нужны эти функции, вам нужно что-то ЛУЧШЕ, чем zip-файлы.

Я использовал ComponentSoftware RCS, и если бы не его низкая производительность в глобальной сети, мы могли бы его использовать: это дешево (даже бесплатно для использование одного разработчика, в том виде, в каком я использовал его дома) и проста в использовании. Однако в настоящее время я бы посоветовал взглянуть на SubVersion. Он очень гибкий, достаточно простой для понимания, имеет хороший набор инструментов Windows, чтобы сделать его еще проще (например, Tortoise, Ankh), и ... самое главное ... вы можете запустить его бесплатно.

Как выполнить слияние? Как вы делаете аннотации? Как вы делите пополам? Где хранятся журналы изменений? Просто зайдите в википедию, найдите «Контроль версий» и пройдите вниз по списку: zip-файлы могут как бы выполнять 2 вещи из всей страницы.

Это похоже на вопрос: «Какие аргументы можно использовать против сокращений, как форма двойной бухгалтерии? ». Совсем другое дело.

Для аргументов есть Уолтер Тихи ' s исходная статья о RCS .

Для отсутствующих функций, среди многих других, есть возможность объединять изменения из разных версий . Это особенно хорошо поддерживается такими инструментами, как git и darcs, и, в меньшей степени, mercurial.

PS Поклонникам Mercurial: проблема в том, что Mercurial делегирует процесс слияния внешним инструментам, и новичку-ртутнику очень сложно узнать, какой инструмент использовать, или понять, как они работают - ртутная модель слияния кажется далекой более мощный, чем другие, но, соответственно, сложный.

PS Поклонникам Mercurial: проблема в том, что Mercurial делегирует процесс слияния внешним инструментам, и новичку-ртутнику очень сложно узнать, какой инструмент использовать, или понять, как они работают - ртутная модель слияния кажется далекой более мощный, чем другие, но, соответственно, сложный.

PS Поклонникам Mercurial: проблема в том, что Mercurial делегирует процесс слияния внешним инструментам, и новичку-ртутнику очень сложно узнать, какой инструмент использовать, или понять, как они работают - ртутная модель слияния кажется далекой более мощный, чем другие, но, соответственно, сложный.

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

Если вы поставите вопрос о контроле качества и укажете на непрерывную интеграцию как на практику, которая ее поощряет, тогда zip Файловый подход к контролю версий - это не «не полностью допустимая форма контроля версий», а препятствие для реализации непрерывной интеграции на практике.

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

Я думаю, ваш лучший аргумент - показать ХОРОШУЮ форму управления версиями и показать, насколько она мощна. Не отбрасывайте то, что делается в данный момент (кто-то наверняка эмоционально привязан к этому). Вы же не хотите выбрасывать «Метод управления исходным кодом ZIP». Покажите силу чего-то вроде SVN. Сделайте это очень простым для объяснения. Показать распространенные варианты использования. (Хорошая демонстрация может помочь.)

Пусть версия для управления версиями продает сама себя.