[dxp 68]

Ха, теперь я занял позицию: не нужен мне этот ваш git, меня и в svn все устраивает :)

:) Это потому что ты feature branches не используешь. В svn с ветками и слиянием всё достаточно печально. Они годятся для крупных ответвлений, но для оперативной работы в параллельных направлениях они слишком тяжелы, а слияние по сути делается на сервере. В git же этот момент реализован очень эффективно - ветка есть указатель на конкретный коммит (коммит в гите - это объект-слепок какого-либо состояния проекта), т.е. ничего не весит, работает это мгновенно. Слияние тоже реализовано хорошо (есть несколько стратегий). А слияние результата работы в ветке (я имею в виду feature branch) со сквошем позволяет не замусоривать историю релизной ветки подробностями о мелких "технологических" коммитах - в истории главной ветки только значимые коммиты с соответствующими внятными сообщениями.

 

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

 

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

[AlexandrY 3]

Минуточку! :) Там в списке достоинств гита был ещё пункт "быстрое, удобное ветвление и слияние". А это очень крутая штука.

Всё же git vs svn гораздо лучше, чем "крутым ымбеддерам системы контроля версий не нужны" :)

 

Очень кривая технология.

Поскольку "быстренько занычиваю" не что иное как переписывание файлов туда-сюда.

При этом не имеете одновременно двух копий сразу. А главное это все из командной строки! Жесть.

 

а в реп фиксировать всё-таки какие-то более-менее логически и технически законченные версии.

 

Как это у вас получаются незаконченные версии.

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

С другой точки зрения законченных версий вообще не бывает, всегда идет развитие.

 

 

 

 

 

[FatRobot 4]

Разница в VCS видна лишь утонченным сомелье. Если просто и без изысков работать, то сгодится любая, и ничем они с точки зрения неискушенного пользователя не отличаются.

 

Я раньше в этой ветке приводил список команд, которые нужны для начала работы. Так вот, 95% пользователей VCS нуждаются исключительно в этих командах в 99% случаев.

[ZASADA 0]

Скажем, сижу я, работаю над одной новой функцией. Тут является начальник, и говорит мне:

"Сейчас приедут заказчики, нужно срочно показать прибор."

Тогда я быстренько занычиваю текущее состояние проекта, переключаюсь на стабильную ветку (git checkout master), компилирую прошиваю, демонстрирую. После этого возвращяюсь к отложенному состоянию, и продолжаю работать как ни в чём не бывало.

а просто хранить на случай таких гостей готовую стабильную откомпилированную прошивку и прошивать ее по необходимости - не вариант?

[AHTOXA 18]

а просто хранить на случай таких гостей готовую стабильную откомпилированную прошивку и прошивать ее по необходимости - не вариант?

То есть, вы предлагаете мне в процессе разработки программы для каждой получившейся рабочей версии (после добавления каждой новой функции) создавать откомпилированную прошивку и где-то её хранить? Может ещё и исходники заодно рядышком архивировать? Так это вы не по адресу, это вам к AlexandrY :).

[kolobok0 0]

...Тут является начальник, и говорит мне:...

 

ну как бы SVN это на ура делает...

 

 

... предлагаете...для каждой получившейся рабочей версии...

 

хачу заметить что система хранения версий - это инструментарий. Им можно пользоваться по разному.

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

В других конторах есть текущая версия(разрабатываемая. коммиты = исправления и фичи) и отслоения по релизным веточкам(коммиты = исправления).

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

библиотек и окружения солюшена...

 

короче говоря потуги сезонные. кто весною решил круто всё упорядочить, кто осенью...разные обострения и взгляды :)

причём ослинные уши начинают сильно задевать за лодыжки в момент интеграции с другим софтом процесса разработки.

от тут косяки упорядочивания стаями слетаются..

Изменено 28 октября, 2014 пользователем kolobok0

[AHTOXA 18]

ну как бы SVN это на ура делает...

Что именно svn делает на ура? Позволяет без доступа к серверу вести параллельную разработку в нескольких ветках, сливая результаты в стабильную ветку? Позволяет (опять же без доступа к серверу) в произвольный момент времени переключиться из рабочей ветки в стабильную без коммита/потери промежуточного результата?

Позволяет без доступа к серверу сдеолать дифф с любой версией?

Нет, svn этого не делает. Ни на ура, ни как либо иначе. С доступом к серверу часть этих функций можно реализовать на svn. Но это уж точно не будет так легко и непринуждённо, как с git.

хачу заметить что система хранения версий - это инструментарий. Им можно пользоваться по разному.

Спасибо, Кэп! :)

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

[AlexandrY 3]

То есть, вы предлагаете мне в процессе разработки программы для каждой получившейся рабочей версии (после добавления каждой новой функции) создавать откомпилированную прошивку и где-то её хранить? Может ещё и исходники заодно рядышком архивировать? Так это вы не по адресу, это вам к AlexandrY :).

 

Это называется сеять самому себе грабли.

Ну какие вы там функции то себе придумываете ради которых надо создавать отдельные ветки (версии)?

И что потом помните в какой версии какая функция?

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

Потом открывать редактор и т.д.

 

Далее ИМХО.

 

GIT создавался для линукса и ветки в нем просто фильтры от гигантского количества мусора от чужих платформ.

И планировалось в нем долго и обособленно работать с небольшим количество файлов относящихся к определенной платформе.

Потому там и не экономят место, но зациклены на быстроте. Ибо файлов во всем дистрибутиве десятки тысяч.

Инструмент явно не для малых embedded систем.

 

 

 

 

 

 

[kolobok0 0]

Что именно svn делает на ура?...

 

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

всё с серваком(изначально речь вроде как про это не пробегало). параллелить, сливать, дифф - всё это с серваком он делает...

 

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

но с кочки зрения процесса разработки, в плане организации на предприятии, централизованное хранение исходников - есть выигрышная вещь.

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

под каким нить серваком непрерывной разработки. тем самым получая ОБЪЕКТИВНО количественный результат для оценки текущего состояния дел.

или немного по другому - фидбэк быстрее, оценка быстрее, подправление процесса(если не туда ползёт) быстрее, обнаружение ошибок быстрее.

 

возможно гит хорош когда команда разработчиков вылетает на самолёте и надо срочно что то создать на коленке - хз...я скорее всего не чувствую

этот момент и соответственно плюсы такого подхода...

Изменено 28 октября, 2014 пользователем kolobok0

[syoma 1]

Я тоже про начальника не сильно согласен.

Достаточно просто локально сделать чекаут стабильной ветки и своей ветки разработки. Переключение между ними - просто переход в другую папку в експлорере.

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

По поводу с сервером или без - это как кому нравится имхо

[AHTOXA 18]

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

Вот в этом-то всё и дело : "не юзал, но мнение имею". Гит даёт всё то же, что и свн, плюс много больше, за счёт локального репозитория, быстрых веток и возможности синхронизации с несколькими удалёнными серверами. То есть, централизованное хранение исходников - очень даже присутствует, а распараллеливание задач - вообще родная стихия гита.

 

Достаточно просто локально сделать чекаут стабильной ветки и своей ветки разработки. Переключение между ними - просто переход в другую папку в експлорере.

Ага. Скачать мегабайты, сейчас, положим, можно быстро. А перенастроить среду разработки и сборки на другую папку?

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

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

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

 

Короче, друзья. Почитайте про гит, попробуйте, и уже потом выносите суждение.

Вот, например, неплохое начало. Пара-тройка вечеров, и вы уже в теме.

Ну или классическая книжка про гит (или её версия в pdf).

 

[AlexandrY 3]

Ага. Скачать мегабайты, сейчас, положим, можно быстро. А перенастроить среду разработки и сборки на другую папку?

 

Это интересно. Какая у вас среда разработки? И почему ее надо перенастроить?

Не знаете конфигурационных файлов своей среды?

Среда не поддерживает относительных путей?

 

И зачем все таки версии и ветки если просто добавляете несложные функции в программу?

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

 

Пока сценарии приводимые для использования с GIT малореалистичны. Как будто придуманы. Либо присутствуют больее серьезные вынуждающие обстоятельства (например тот самый начальник).

 

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

 

[syoma 1]

Кстати, хотел спросить по SVN - и использование externals.

Допустим у меня есть trunk-и для разных проектов со своими папками, но, допустим, один человек хочет иметь у себя только папки models из всех этих транков в одной локальной папке. Чтобы не лазить по репозиторию и не делать индивидуальные чекауты, можно ли просто создать в репозитории пустую папку с названием all_models, например, у которой в свойствах externals были бы заданы все нужные папки? Чтобы при ее чекауте все они вытаскивались автоматом.

В принципе коммиты в этом случае не требуются - в основном это для быстрого обзора.

 

Существует такая практика?

[AlexandrY 3]

Существует такая практика?

 

Конечно существует. ;)

Ручками пишутся скрипты для SVN сервера с использованием svnsync.

Создавайте еще один программный проект, учитесь писать скрипты, потом заниматься поддержкой, привыкайте к командной строке... Не ленитесь короче ;)

[dxp 68]

Кстати, хотел спросить по SVN - и использование externals.

Допустим у меня есть trunk-и для разных проектов со своими папками, но, допустим, один человек хочет иметь у себя только папки models из всех этих транков в одной локальной папке. Чтобы не лазить по репозиторию и не делать индивидуальные чекауты, можно ли просто создать в репозитории пустую папку с названием all_models, например, у которой в свойствах externals были бы заданы все нужные папки? Чтобы при ее чекауте все они вытаскивались автоматом.

В принципе коммиты в этом случае не требуются - в основном это для быстрого обзора.

 

Существует такая практика?

Да, всё можно. Создаёте свою директорию all_models, в её свойствах задаёте svn:externals, где для каждого external'са будет пара <dir_name> - <url_path> (dir_name - название местной директории, url_path - полный путь до директории в стороннем репе). Затем svn update, и вуаля. Если есть доступ по записи в те репы, то можно вносить правки и коммитить.