Alexey TominBig17Могу еще подсказать VisualSVN Server - ставиться как служба, минимум заморочек - и сразу можно работать.

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


Для работы с SVN единственному разработчику никакой сервер не нужен.
Весь функционал контроля версий доступен из утилит командной строки.
Никакая служба не нужна. "Развертывание" элементарнейшее -
создал репозиторий svnadmin create и работай.

DVCS для одного разработчика - ненужный overhead, IMHO

Alexey TominУ меня 15 лет опыта работы (ежедневной) с "обычными" vcs (cvs -> vss -> svn) и 2.5 года с git. Могу сравнить.
А у Вас какой опыт? Интересно знать, откуда "оверхед".

15 лет опыта работы, но при этом вы не знаете то, что SVN не требует выделенного сервера для работы в режиме использования одним разработчиком ? ;-)

О чем тут спорить ?

У меня к вашему списку (cvs -> vss -> svn) еще добавляется ClearCase, в котором, я, в свое время, прямо в бинарнике кое что подправил, чтобы лучше работал ;-)

Ну да ладно, дело прошлое.

Под словом "оверхед" следует понимать ненужный функционал.

Зачем одному человеку пользоваться распределенной системой
контроля версий ? в чем профит ?

Alexey Tominaddyyпропущено...


15 лет опыта работы, но при этом вы не знаете то, что SVN не требует выделенного сервера для работы в режиме использования одним разработчиком ? ;-)

Когда я работал один, то использовал cvs. SVN внедрял на команду из 5 человек. Так что не надо было.

addyyУ меня к вашему списку (cvs -> vss -> svn) еще добавляется ClearCase, в котором, я, в свое время, прямо в бинарнике кое что подправил, чтобы лучше работал ;-)

Ну да ладно, дело прошлое.

Под словом "оверхед" следует понимать ненужный функционал.

Зачем одному человеку пользоваться распределенной системой
контроля версий ? в чем профит ?

Т.е. опыта с git'ом нет, как я понял? Где у него оверхед? Просто не читай про pull/push/fetch - и всё. Не надо никаких служб ставить, ничего.
Ставить - apt-get install git.
Создать - git init.
Куда уж проще.


Я не использую Git в работе, но пробовал, сравнивал, как и много чего другое.
Экспертом в нем себя не считаю, но возможности представляю.

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

Зачем нужно применять DVCS одному разработчику ?
Какой смысл ?

Alexey TominBig17Могу еще подсказать VisualSVN Server - ставиться как служба, минимум заморочек - и сразу можно работать.

Я не вижу ни одного плюса svn перед dvcs (git, или hg). Вообще ни одного.


Раз такое дело, то спрошу.

Допустим, есть сетевой репозиторий в 30 ГБ я хочу получить из него только один файл .
Локального, синхронизированного с ним репозитория на моей машине нет.
Как в Git это сделать ?

Забыл команду.

addyyпропущено...

Раз такое дело, то спрошу.

Допустим, есть сетевой репозиторий в 30 ГБ я хочу получить из него только один файл .
Локального, синхронизированного с ним репозитория на моей машине нет.
Как в Git это сделать ?
Забыл команду.

Alexey TominДля такого случая команды нет.


Вот об этом и речь
Есть еще немало сценариев использования SVN которые в Git не повторить.
Утверждать, что Git лучше всегда - как минимум некорректно ;-)

Понимаете, если говорить слово "Stash" то и к SVN прикрутить/дописать
можно что угодно.

Но похоже есть другой, более принципиальный вопрос.

addyyЯ не использую Git в работе, но пробовал, сравнивал, как и много чего другое.
...
Зачем нужно применять DVCS одному разработчику ?
Какой смысл ?

Alexey Tomin
Например потому, что он ПРОЩЕ в использовании одному разработчику локально, чем SVN.
Пока я не использовал активно GIT я тоже считал, что SVN лучше и проше.
А сравнив в ежедневном использовании- пришёл к тому выводу, что сказал- смысла в SVN нет никакого вообще. Всё, legacy.

Плюс GIT, например, в том, что он отлично мержит ветки, в отличии от SVN. Это связано с тем, что при мерже двух веток по 50 коммитов SVN одну из веток сливает (всегда) в один коммит и в результате путается, а GIT- работает с полной историей.
Опять же- у меня есть достаточно опыта в обоих системах, чтобы сравнить.


Давайте разберемся.

Я не понимаю что вы имеете ввиду под "слиянием веток", вернее, какую роль это играет в вашем процессе.

Что это за операция ?
Это периодическая синхронизация одной ветки с другой ?
Или же финальное слияние, после которого ветка больше не нужна ?

И что такое "полная история" ?

Alexey TominДело в том, что для SVN ВСЕГДА поднимается сервер. Локально, удалённо- не важно. Вроде есть разные варианты.





Нет, давайте разбираться.
Что такое сервер тогда ?

Я опять не понимаю.

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

Вот прямо сейчас у меня на ноутбуке установлен SVN, есть репозиторий, я могу с ним работать, а никаких процессов,
относящихся к SVN в памяти ОС нет. Как Сервер может быть поднят, если нет процессов ?

Я думаю, что никак.

Если возникает вопрос: а как же тогда все работает, если сервер не поднят ?
Отвечаю:

Функционал контроля версий заработает только тогда и только в тот момент , когда я запущу утилиту (тот же svn) и передам этой утилите какую-то команду. Команда загрузит динамическую библиотеку, динамическая библиотека отработает с репозиторием
на уровне вызовов файловой системы . После отработки команды утилита выгрузится из памяти, выгрузится и используемая ей динамическая библиотека.

Вопрос. Где здесь сервер ?

Alexey Tominдля git'а можно сервер вообще не поднимать (как для CVS). А можно и сделать его- stash, gitlab, rhodecode.
Так что кто здесь выигрывает? Гит- он может работать как с сервером, так и без. Без- один файл не скачать, но без сервера нет SVN вообще (локальный сервер нужен).



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

Еще раз: Где здесь сервер ?

Я когда начинал работать а SVN не помню точно в каком году, может в 2003 или около того, ставил Apache даже на локальную машину и работал с SVN через него. Но это только потому, что я не разобрался тогда в теме, а ставил все по
How-to, где описывался только такой вариант конфигурации. Потом, когда я осилил документацию, я понял, что так делать
необязательно никакие процессы не нужны, никакой сервер не нужен.

Вы все еще настаиваете что без сервера SVN не работает ?

Alexey TominaddyyВы все еще настаиваете что без сервера SVN не работает ?

Нет, не буду.
Хорошо, тогда вопрос (в ответку про "как скачать один файл")- вот у меня есть linux, я хочу начать работать с svn локально. Что надо сделать?
С git - выполнить две команды.
Одну один раз (чтобы инсталировать гит) вторую для создания пустого репозитория.
Где оверхед по сравнению с svn?


С SVN все абсолютно аналогично.
Устанавливаем SVN, можно даже ничего не устанавливать
нужны только исполняемые файлы/библиотеки (ну это я думаю очевидно и так)

Создаем репозиторий. Все, можно работать.
Никаких дополнительных настроек для работы с SVN без сервера не требуется.

Может быть дело в пакетах - я из пакетов никогда ничего не устанавливаю,
если есть src


Alexey TominНа самом деле мне стыдно за те ДЕСЯТКИ (я не преувеличиваю) часов, потраченных в пустую из-за того, что я вовремя не перешёл (и не перевёл свою группу в пяток человек) с svn на git. И не хочу, чтобы другие прошлись по тем же граблям. Лучший способ для этого- сразу изучать git (или hg).


Верю, но тут вопрос субъективный.
Если инструмент вам не подходит для вашего сценария использования, то это не вина инструмента, согласитесь ?
Я вот не хочу синхронизировать свой репозиторий с сетью, ради того, чтобы выкачать одну ветку или один файл.
Для меня вот это минус и минус существенный.

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

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

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

Например, Модель GitFlow на SVN вполне реализуема.

А какие-то другие вещи или частные случаи - видимо нет.
Значит надо разбираться ;-)

oragrafaddyy,

Ну ка, что будешь делать в таком случае? Приходишь к заказчику с одной флешкой со скриптами, инета нет . Тебе надо попробовать погонять скрипты в разных вариациях, периодически в них что-то подпиливая. Причем эти подпиливания нужно сохранить и принести к себе на работу, чтобы выбрать лучшее. Твои действия с свн? Копипаст по папкам? Локальный реп на флешке? Ок. А потом на работе у себя как сливать в центральный? опять копипаст из одного места в другое
Только поработав с гит, я понял силу веток и мерджей.

Спасибо за вопрос.

Ну, давайте порассуждаем.

Репозиторий на флешке это уже что-то, но раз инета нет, то пусть будет так.
Пусть будет репозиторий SVN на флешке

У меня дополнительный вопрос:

Что вы хотите сохранить в центральном репозитории ?
Вот на флешке у вас репозиторий, в нем история изменений скриптов.
Вам нужно перенести эту историю в центральный репозиторий ?
Чтобы она не потерялась и можно было "шагам пройтись" по всей истории
изменения diff и все прочее ? Для этого вам нужна история ?

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

но если под это дело зарядить систему контроля версий, по условиям задачи,
тогда так

1) svn mkdir в центральном репозитории создаю директорию (ветку)

2) svnadmin dump для репозитория с флешки
3) svnadmin load --parent-dir моя директория из шага 1

Все

oragrafaddyy,

Ну ка, что будешь делать в таком случае? Приходишь к заказчику с одной флешкой со скриптами, инета нет . Тебе надо попробовать погонять скрипты в разных вариациях, периодически в них что-то подпиливая. Причем эти подпиливания нужно сохранить и принести к себе на работу, чтобы выбрать лучшее. Твои действия с свн? Копипаст по папкам? Локальный реп на флешке? Ок. А потом на работе у себя как сливать в центральный? опять копипаст из одного места в другое
Только поработав с гит, я понял силу веток и мерджей.

В моем примере решения (см. выше) разумеется есть минусы

Самый очевидный: рассинхронизация номеров коммитов на флешке и в центральном репозитории.
Но ведь с репозиторием на флешке мы больше работать не будем ? За этим сливаем
изменения в центральный репозиторий ?

А комментарии при коммите указываем наверное за тем, чтобы в случае чего, по ним
что-то найти, а не по номерам коммитов ?

oragrafaddyy,

1. Я хочу принести историю изменений потом в офис. Коммитить или нет и что конкретно коммитить в центральный реп - я решу потом.
2. Вопрос был не в том, что ты в офисе делать будешь. Вопрос был в том, как ты сохранишь историю своих изменений у заказчика.
3. Про функциональность и вынос в модули - у меня есть набор sql-скриптов. Какая там функциональность и модули? Но их тоже скомпоновать и написать можно сильно по-разному.

Я не понял, почему есть вопрос " как ты сохранишь историю своих изменений у заказчика "
Откуда он вообще берется ?
В чем вообще здесь проблема ?

Да, создается локальный репозиторий, того же SVN

Создается где угодно. Хоть на флешке, хоть на сервере/компе у клиента.
Потом достаточно его выгрузить командой svnadmin dump в файл
этот файл принести с собой.

Дальше из него можно создать
1) Отдельный репозиторий на своем ноутбуке, скажем
2) Перенести историю прямо из файла в центральный репозиторий

3) При желании, слить какую-то версию какого-то файла "от заказчика"
с таким же или другим файлом из центрального репозитория.

В чем вопрос, я не понимаю ?

Да, в Git это штатный функционал, это распределенная система,
но в SVN эта задача решается тремя командами, можно и двумя, но лучше тремя ;-)

oragrafaddyy,

3. Про функциональность и вынос в модули - у меня есть набор sql-скриптов. Какая там функциональность и модули? Но их тоже скомпоновать и написать можно сильно по-разному.

SQL скрипты - текстовые файлы, так ?
Любая система "сборки" текстовых файлов, любая шаблонная система вам подойдет.

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

oragrafaddyy,

я правильно понимаю, что ты:
1. делаешь из дампа центральный реп на ноуте и коммитишь туда все изменения?
2. приходишь в офис и сливаешь эти изменения в центральный реп в офисе?


Да, почти.
Я так не делаю, ибо вижу другое решение задачи.

Но если отталкиваться от того, что сформулировано в условии задачи - то все верно.
Так делать можно. Можно и с SVN иметь хоть сколько угодно
репозиториев, хоть миллиард.

Один у заказчика, один на флешке, другой на ноутбуке, третий на сервере.

Минус только в том, что замучаешься синхронизировать, не предназначена
для этого система.

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

oragrafaddyy,

я правильно понимаю, что ты:
1. делаешь из дампа центральный реп на ноуте и коммитишь туда все изменения?
2. приходишь в офис и сливаешь эти изменения в центральный реп в офисе?

Я никогда не понимал, почему Git ставят в заслугу "вы можете работать с ним без интернета, например, в самолете"
типа потому, что это децентрализованная система. Да, децентрализованная, да, она на это рассчитана.
Но с SVN все тоже самое можно делать, с некоторыми оговорками, но их мало кто заметит.

У меня на компьютере есть локальный /не сетевой / без сервера / без инсталяции репозиторий
для экспериментов. Я им пользуюсь, в основном, как "многоуровневым Undo".

Мне так удобнее, конечно можно и по-другому работать, вопрос в том, какие + и - у подходов ;-)

oragrafaddyy,

я правильно понимаю, что ты:
1. делаешь из дампа центральный реп на ноуте и коммитишь туда все изменения?
2. приходишь в офис и сливаешь эти изменения в центральный реп в офисе?


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

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

После всех необходимых действий, доработок,
дамп репозитория с ноутбука передается на центральный сервер.

Вся история сохранится, но разумеется, поскольку в SVN номера
коммитов глобальны на уровне репозитория, после заливки
дампа одни и те же изменения будут иметь разные номера коммитов
в ноутбучном репозитории и репозитории сервера. При желании,
можно и это побороть ;-)

Схема с дампом плохо (мягко скажем) работает для двухсторонней репликации,
а если все изменения и вся история идут по цепочке все время в одну
и ту же сторону, тогда она вполне рабочая.

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

То есть, к заказчику можно прийти уже с репозиторием на флешке,
где будет история, если нужно.

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

Но все решаемо, если все изменения брать / заливать
в свою ветку (директорию) и если с этой веткой
работает только один человек.

Возможно, в подходе есть какие-то существенные проблемы,
подводные камни, которые я не учел.
Кто их видит - отпишитесь.