Несколько вопросов об управлении базовой версией
Существует много способов, которыми это можно сделать, или по крайней мере помочь. Поисковый Google для "slashdot-защищенного" и Вы найдете много ими:
- Slashdot-защищенный Ваш сервер с FreeCache - Boing Boing
- Простой Блог Мыслей является теперь Доказательством Slashdot
и т.д.
8 ответов
Отчасти ваше замешательство, вероятно, связано с разными системами контроля версий (VCS), которые по-разному используют терминологию.
Я обычно думаю о коде «строками». Я начинаю с исходной версии файла и сохраняю ее в своей системе контроля версий. Помещение его в VCS называется "проверкой на входе". Система контроля версий помечает его некоторым номером, например, версия 1.0. Сейчас компилирую программу. Он ломается, поэтому мне нужно его отредактировать. Для этого я «проверяю» его в системе контроля версий и редактирую. Теперь, когда он исправлен, я возвращаю его обратно, и система контроля версий сохраняет его как ревизию 1.1. Моему боссу нужна новая функция, поэтому я проверяю ее, редактирую и снова возвращаю, и она сохраняется как версия 1.2.
Это «основная строка» или «ствол» кода.
Система контроля версий позволит вам получить любую старую версию файла, указав номер ревизии. Допустим, я получил отчет об ошибке от программного обеспечения, основанного на версии 1.1. Я могу использовать "diff" или любой другой инструмент сравнения, чтобы сравнить 1.1 с 1.0 и посмотреть, что изменилось. Неважно, как система контроля версий хранит его внутри, я просто запрашиваю его по номеру ревизии и получаю весь файл.
Следующее, что нужно понять, это то, что группа файлов составляет ваш проект или решение. Когда вы собираетесь скомпилировать свое программное обеспечение, чтобы выпустить его в мир, вы хотите связать «метку» со всеми этими файлами, чтобы вы могли рассматривать их все как группу. Большинство людей используют числовые метки, такие как Windows 3.0, Windows 3.51 и т. Д., Но это просто соглашение. Вы можете обозначить версию «выносливая цапля» или « В версии 10 (над которой вы работаете в другой папке) вы работаете с версией 1.40. Вы не хотите, чтобы изменения для версии 7 вошли в 1.41, потому что это перезапишет и уничтожит все аккуратные функции, которые вы добавили в версиях с 1.24 по 1.40. Итак, вы создаете ветку и регистрируете измененный файл как версию 1.23.0.1. Вы компилируете его, и теперь ошибка исправлена. И теперь вы должны предоставить его своим клиентам. Когда вы отпускаете, вы создаете новый лейбл. Я бы назвал это чем-то вроде «версия 7.1», чтобы я мог отличить сломанное программное обеспечение от исправленного. И я бы знал, что в нем не было всех функций версий 8+.
Если вы нанесете эти версии программного обеспечения на линию, вы подумаете о числовой прямой, идущей прямо от 1 до 10. Где 7 . 1 подходит к этой линии? Он торчит сбоку, как ветка из ствола дерева. Отсюда мы и получили названия «ветка» и «ствол».
I think you (and anyone who doesn't quite understand version control) should read Eric Sink's articles on the subject.
На самом деле вам не нужна ветка, если вам не нужно работать отдельно над двумя разными наборами кода для одного и того же проекта. Ветвление гораздо чаще встречается в групповой среде, где большинство разработчиков будут работать над более долгосрочными функциями в магистрали, в то время как один или два создают ветвь для более раннего выпуска конкретной функции. Затем они объединяли бы эту ветвь обратно в ствол, так что весь код снова был в одном месте. Это всего лишь один пример ...
Я рекомендую просто создать репозиторий Subversion (в идеале на другом сервере, но если он должен быть на вашем компьютере, это лучше, чем ничего) и зафиксировать (протолкнуть) ваш там меняется. Вы всегда можете обновить вашу локальную рабочую копию (вытащить) из репозитория.
Subversion выполняет двоичное сравнение файлов, поэтому сохраняет только разницу, а не всю копию. Это может быть проблемой, если у вас много переименований / удалений (особенно каталогов) в ветках, но все будет нормально, если вы останетесь в стволе.
Если вас беспокоят эти проблемы, я рекомендую Mercurial или Git , которые создают (клонируют) целые копии репозитория (без двоичных различий). Если вы разбираетесь в графическом интерфейсе, у Mercurial сейчас немного лучше интерфейс Windows. Однако у Mercurial и Git нет того же интегрированного инструментария, который есть у svn (например, с Ankh).
Я использую svn с Ankh для VS2008, и в целом мне он нравится (особенно Ankh!), Хотя Меня несколько раз обжигала проблема удаления / переименования каталога в svn ...
Удачи!
Ной
тогда я рекомендую Mercurial или Git, которые создают (клонируют) полные копии репозитория (без двоичных различий). Если вы разбираетесь в графическом интерфейсе, у Mercurial сейчас немного лучше интерфейс Windows. Однако у Mercurial и Git нет того же интегрированного инструментария, который есть у svn (например, с Ankh).Я использую svn с Ankh для VS2008, и в целом мне он нравится (особенно Ankh!), Хотя Меня несколько раз сжигала проблема удаления / переименования каталогов в svn ...
Удачи!
Ной
тогда я рекомендую Mercurial или Git, которые создают (клонируют) полные копии репозитория (без двоичных различий). Если вы разбираетесь в графическом интерфейсе, у Mercurial сейчас немного лучше интерфейс Windows. Однако у Mercurial и Git нет того же интегрированного инструментария, который есть у svn (например, с Ankh).Я использую svn с Ankh для VS2008, и в целом мне он нравится (особенно Ankh!), Хотя Меня несколько раз обжигала проблема удаления / переименования каталога в svn ...
Удачи!
Ной
Неверно, это просто новая ревизия. Ветвление - это то место, где ваш поток изменений «разветвляется» в двух или более направлениях. Обычно это особая операция, отличная от добавления и удаления файлов.
Как и раньше, на этом этапе вы не выполняли разветвление. Обычно вы выбираете, в какой ветке вы находитесь, с помощью инструмента контроля версий. Я настоятельно рекомендую посмотреть документацию по ветвлению для любого инструмента, который вы хотите использовать.
Большинство инструментов управления Versin сохраняют только различия между версиями файла. Некоторые (особенно CVS) будут делать это только для текстовых файлов, а изменения в двоичных файлах приведут к сохранению полной копии новой версии. Обратите внимание, что это не мешает вам получить полный файл любой данной ревизии, это исключительно вопрос того, как хранятся данные.
Вы можете получить полное состояние любой выбранной ревизии в любое время.
С централизованной системой управления версиями (CVS, Subversion) вы фиксируете изменения в репозитории и получаете данные из репозитория. С децентрализованной системой управления версиями (git, mercurial, darcs, bazaar) вы клонируете удаленный репозиторий (или создаете свой собственный локальный репозиторий), фиксируете изменения в этом репозитории, а затем можете отправлять наборы изменений в другой удаленный репозиторий или извлекать наборы изменений из удаленный репозиторий. Различие состоит в том, что каждый разработчик имеет свою собственную копию репозитория и генерирует наборы изменений в своей копии, и чтобы другие люди могли их видеть, эти наборы изменений необходимо перенести в общее место, откуда другие люди могут их вытащить. У IBM есть достойное введение в концепцию распределенного контроля версий.
Я думаю, вы найдете полезными следующие сведения: Иллюстрированное руководство по Git в Windows .
1) Филиалы полностью под вашим контролем, система SC победила не удивлю вас ими (за исключением нескольких головок в распределенных системах, но ваш пример не должен вызывать этого.) Теперь, если вы проводите серьезную реорганизацию, вы можете создать новую ветку, чтобы вы могли легко держать их отдельно, но это ваш выбор.
2) Если вы решите использовать ветки, вы можете продолжить разработку, какую захотите. Пока ваши изменения зафиксированы, у вас есть контрольная точка, и вы можете свободно перемещаться между ними. В некоторых случаях вы можете даже поделиться изменениями между ними, но я бы не стал сразу вдаваться в это.
3 и 4) Большинство систем сохранят различия из-за экономии места, но это деталь реализации. Вы можете получить любую версию в любое время точно в том виде, в котором она была зафиксирована.
5) Коммит устанавливает контрольную точку, к которой вы можете вернуться позже. Push и pull относятся к совместному использованию изменений между вами и другим сервером или репозиторием; push - это отправка куда-то изменений, pull - загрузка чужой работы. Централизованные системы, такие как Subversion, подразумевают отправку с фиксацией и требуют, чтобы вы были в курсе последних событий. Распределенные системы позволяют (и требуют) выполнять каждую часть отдельно.
1) например, как описано, я поставил первую версию в vc. потом Я удаляю все файлы и перезаписываю их заново. Если бы я хорошо понял, это бы быть новой «веткой», не так ли?
Вы правы, думая, что перезапись должна рассматриваться как новая ветвь, но вам придется сообщить вашей системе контроля версий, что вы создаете новую ветку.
2 ) если я продолжу развивать это версия, я бы просто продолжал совершать в эту "ветку"?
Да.
3) сохраняет ли vc при сохранении точка сохранения в ветке, все файлы в, или это просто экономит разницу между ними?
Я считаю, что большинство систем управления версиями хранят дельты между ревизиями вместо целых файлов, чтобы сэкономить дисковое пространство.
4) Могу ли я легко получить все (целые project) файлы из определенного точка сохранения в ветке, или у меня есть проследить это через diff, пока начало ? (Я просто хочу быть может сказать: "вот, это точка сохранения - скопируйте все нужные файлы так это выглядит так ")
Большинство систем контроля версий позволяют проверить любую ревизию.
5) что это означает, в очень простыми словами, «толкать» и «тянуть». я не понимаю разницы между «push» / «pull» и «commit».
Распределенные системы контроля версий имеют команды «push» и «pull» для загрузки или выгрузки изменений на удаленный сервер и команду «commit» для сохранения изменений на локальном репозиторий. Это контрастирует с SVN, который хранит информацию о версии только на стороне сервера, поэтому с SVN вы "фиксируете" на удаленном сервере.
Я постараюсь ответить на ваши вопросы по очереди.
1) например, как описано, я поставил первую версию в vc. потом Я удаляю все файлы и перезаписываю их заново. Если бы я хорошо понял, это бы быть новой «веткой», не так ли?
Удаление файлов и перезапись с нуля не является отличительной чертой ветки. Представьте себе ствол и ветку. Распространенным шаблоном является хранение кода для текущей (последней и самой большой) разработки в основной ветке. Затем в какой-то момент вы захотите выпустить свой код, и тогда вы сделаете снимок ствола. Этот снимок - ветка.
2) если я продолжу развивать это версия, я бы просто продолжал совершать в эту «ветку»?
Да, вы можете продолжать разработку кода в магистрали и кода в ветке независимо.
3) сохраняет ли vc при сохранении точка сохранения в ветке, все файлы в, или это просто экономит разницу между ними?
С вашей точки зрения, просто думайте о ветке как о снимке, а не как о последовательности различий. Внутри разные продукты реализуют ответвления по-разному, но вам не нужно беспокоиться об этом.
4) Могу ли я легко получить все (целые project) файлы из определенного точка сохранения в ветке, или у меня есть проследить это через diff, пока начало ? (Я просто хочу быть может сказать: "вот, это точка сохранения - скопируйте все нужные файлы так это выглядит так ")
Повторюсь, подумайте о ветке как о снимке файлов.
5) что это означает, в очень простыми словами, «толкать» и «тянуть». я не понимаю разницы между "push" / "pull" и "commit".
Такие системы, как sccs, cvs, svn, perforce, clearcase, поддерживают центральное хранилище ресурсов. Пользователи помещают свои локальные копии в репозиторий. В svn это делается с помощью svn commit. Такие системы, как git и mercurial, поддерживают распределенный репозиторий активов, а пользователь извлекает файлов из других репозиториев для обновления своего собственного репозитория.