Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 166
Мы используем Perforce для корпоративных проектов.
Вот и мы тоже. Остается узнать, его только в моей компании тихо ненавидят, или у вас тоже?
Все относительно. Streams добавляют функционал похожий на Git. Но в целом да, люди всегда ненавидят громоздкие проекты ;)
Мне, в принципе, perforce нравится. Шустрый, огромное количество команд. Иногда, конечно, приходится покопаться долго, чтобы разобраться, как нужно заставить его сделать то, что необходимо. Но после того, как поработаешь с ним месяц — запомнишь все стандартные подходы — все становится намного проще. Я, практически, все делаю из командной строки, если это важно.
Правда для development использую «git p4», так как приходится часто переключаться между задачами. В моем случае репозиторий одного бранча без истории получается около 2.3Gb (только папка .git), если кому интересно.
Правда для development использую «git p4», так как приходится часто переключаться между задачами. В моем случае репозиторий одного бранча без истории получается около 2.3Gb (только папка .git), если кому интересно.
Просто любопытно, какой тип файлов занимает 80% места?
tar.gz, если любопытно. В них содержатся всякое, чаще всего исходники каких-нибудь сторонних продуктов, библиотек, утилит, которые используются при сборке, при поставке и т.п.
Хранить или не хранить — это холиварный вопрос. Если вам действительно хочется об этом поговорить именно со мной, то мы, конечно, можем. Но скажу так, я не занимаюсь build системой в компании, в которой я сейчас работаю. Существует она уже порядка 10 лет. Работает она отлично, намного лучше, чем в Visual Studio (где я раньше работал). Проблем у меня с ней совсем нет, поэтому мне нравится и я не жалуюсь.
Отвечая на ваш вопрос, попробую кратко. На вскидку у нас есть 30 проектов от которых мы зависим как-то (используем в билде, используем при поставке своего продукта, используем сам компонент и т.п.), из этого следует:
а) Не хранить их где-то глупо, так как кто знает, может быть завтра github будет лежать, а послезавтра bitbucket. Над этим, я думаю, мы согласимся.
б) Копировать и хранить их в какой-нибудь специальной системе, откуда забирать — вроде как, разумно. Но тогда нужно будет поддерживать и perforce/git, а так же эту вторую систему. Какой смысл в этом будет смысл, если perforce отлично может управляться с большими файлами?
Могу еще немного подитожить. Если все зависимости можно получить из одного места, как например npm (node.js) или nuget (microsoft), и если вы довольны uptime этих систем, то можно не хранить в репозиториях, а подтягивать их при билде, например. Но опять же из примеров, после того, как npm пару дней работал в нестабильном режиме и народ не мог сделать deploy своих node.js проектов — мне интересно, сколько народу после этого убрало node_modules из .gitignore.
Отвечая на ваш вопрос, попробую кратко. На вскидку у нас есть 30 проектов от которых мы зависим как-то (используем в билде, используем при поставке своего продукта, используем сам компонент и т.п.), из этого следует:
а) Не хранить их где-то глупо, так как кто знает, может быть завтра github будет лежать, а послезавтра bitbucket. Над этим, я думаю, мы согласимся.
б) Копировать и хранить их в какой-нибудь специальной системе, откуда забирать — вроде как, разумно. Но тогда нужно будет поддерживать и perforce/git, а так же эту вторую систему. Какой смысл в этом будет смысл, если perforce отлично может управляться с большими файлами?
Могу еще немного подитожить. Если все зависимости можно получить из одного места, как например npm (node.js) или nuget (microsoft), и если вы довольны uptime этих систем, то можно не хранить в репозиториях, а подтягивать их при билде, например. Но опять же из примеров, после того, как npm пару дней работал в нестабильном режиме и народ не мог сделать deploy своих node.js проектов — мне интересно, сколько народу после этого убрало node_modules из .gitignore.
> А я могу кратко, что в сравнении с вашим «попробую» как бы намекает :)
Не понимаю намека.
> Так вот на этой же файловой системе с правами доступа -r------- (400) и есть самое распрекрасное место для архива.
Положить что-то куда-то — это только часть беды. За этим нужно следить — backups, version control (в смысле, что нужно знать, какая версия какой библиотеки используется в каком бранче, для какой версии и т.п.). Так после этого назревает только один вопрос. В чем прелесть по сравнению с хранением их в perforce? Только то, что репозитории будут меньше? Такой проблемы нет, perforce справляется более чем хорошо с этим.
> Что касается ноды, то деплой обычно ждет даже неделю. Ну если это не первый мой проект, который я мечтаю показать всему миру немедленно.
Мы живем с вами в разных мирах.
Не понимаю намека.
> Так вот на этой же файловой системе с правами доступа -r------- (400) и есть самое распрекрасное место для архива.
Положить что-то куда-то — это только часть беды. За этим нужно следить — backups, version control (в смысле, что нужно знать, какая версия какой библиотеки используется в каком бранче, для какой версии и т.п.). Так после этого назревает только один вопрос. В чем прелесть по сравнению с хранением их в perforce? Только то, что репозитории будут меньше? Такой проблемы нет, perforce справляется более чем хорошо с этим.
> Что касается ноды, то деплой обычно ждет даже неделю. Ну если это не первый мой проект, который я мечтаю показать всему миру немедленно.
Мы живем с вами в разных мирах.
> А у вас чем-то из перечисленного занимается perforce?
Может я не верно высказался, но как бы да. Perforce понятное дело бекапится постоянно. Плюс он дает гарантию, что у нас явное соответствие того, что для определенного бранча в этом бранче лежат определенные версии библиотек, за этим следить не нужно. Случайно никто ничего не удалит и не порушит, так как в perforce есть история, ну и как я уже сказал — есть бекапы. Все, вроде, логично.
> Ну тогда понятно, зачем ежедневные деплои :)
Вы сделали не верные выводы. Если интерес в разговоре был только в том, чтобы доказать, что вы умный, а я глупый, то давайте на этом закончим.
Может я не верно высказался, но как бы да. Perforce понятное дело бекапится постоянно. Плюс он дает гарантию, что у нас явное соответствие того, что для определенного бранча в этом бранче лежат определенные версии библиотек, за этим следить не нужно. Случайно никто ничего не удалит и не порушит, так как в perforce есть история, ну и как я уже сказал — есть бекапы. Все, вроде, логично.
> Ну тогда понятно, зачем ежедневные деплои :)
Вы сделали не верные выводы. Если интерес в разговоре был только в том, чтобы доказать, что вы умный, а я глупый, то давайте на этом закончим.
для хранения tar.gz имеет смысл попробовать git-annex
У них же perforce, а гит только у автора, в режиме эмуляции.
Какой тут annex.
Какой тут annex.
git-annex инетесное решение. Но, как уже сказали — мы используем perforce.
В случае git + git-annex — нужно поддерживать две системы, а в случае perforce — только одну. Думаю для людей, сопровождающих наш репозиторий и билд окружение — выбор будет очевидным. Я бы выбрал perforce.
В случае git + git-annex — нужно поддерживать две системы, а в случае perforce — только одну. Думаю для людей, сопровождающих наш репозиторий и билд окружение — выбор будет очевидным. Я бы выбрал perforce.
Похоже здесь все знают, почему именно .tar.gz, а не их содержимое в распакованном виде. А мне интересно.
С perforce дело не имел, но git из атрибутов сохраняет вроде только +x и информацию о том, что файл является символической ссылкой, причина в этом?
С perforce дело не имел, но git из атрибутов сохраняет вроде только +x и информацию о том, что файл является символической ссылкой, причина в этом?
Не знаю, была ли проблема с атрибутами. Как я уже говорил, я особо этим не занимаюсь, пришел на готовое. Сам думаю, что не было никаких особых проблем с атрибутами, хотя все может быть. На самом деле, думаю, что так просто проще обновляться:
* История самих этих библиотек нам не нужна.
* Иногда нужно хранить несколько версий самой библиотеки.
* С tar.gz просто сравнить, что у нас точно тоже самое, что сейчас лежит на сайте у производителя библиотеки, по хешу.
В общем, мне кажется, это чисто для удобства обновления и слежения за версиями. Распаковка занимает конечно какое-то время, но это лечится при помощи increment build.
* История самих этих библиотек нам не нужна.
* Иногда нужно хранить несколько версий самой библиотеки.
* С tar.gz просто сравнить, что у нас точно тоже самое, что сейчас лежит на сайте у производителя библиотеки, по хешу.
В общем, мне кажется, это чисто для удобства обновления и слежения за версиями. Распаковка занимает конечно какое-то время, но это лечится при помощи increment build.
Спасибо. Прочитал ветку. Действительно, хорошее решение.
В GIT для хранения вспомогательных или «blob» файлов нужно использовать костыли.
1:0 для Perforce.
А в остальном как? Что из вашего опыта там еще интересного? Можете просто линк скинуть с указанием на то что маркетинговый буллшит, а что действительно работает и помогает.
В GIT для хранения вспомогательных или «blob» файлов нужно использовать костыли.
1:0 для Perforce.
А в остальном как? Что из вашего опыта там еще интересного? Можете просто линк скинуть с указанием на то что маркетинговый буллшит, а что действительно работает и помогает.
Почитал про Perforce и про Jam. Интересные инструменты, попробую поиспользовать.
Можно узнать, за что нужно можно ненавидеть Perforce?
На мой взгляд, это же крутая и мощная централизованная СКВ, особенно по сравнению с SVN просто праздник какой-то! Единственный существенный минус — платная и дорогая. Я много лет работаю с Perforce на рабочих проектах и мне почти всё в ней нравится. Коллеги тоже не жалуются. Из известных компаний Perforce используют Google и Valve.
На мой взгляд, это же крутая и мощная централизованная СКВ, особенно по сравнению с SVN просто праздник какой-то! Единственный существенный минус — платная и дорогая. Я много лет работаю с Perforce на рабочих проектах и мне почти всё в ней нравится. Коллеги тоже не жалуются. Из известных компаний Perforce используют Google и Valve.
На самом деле p4 не так уж и ужасен, однако человеку к нему непривычному поначалу очень сложно.
Мне например не хватает банальной функции создать файл патча. Я понимаю. что есть шелв, однако это не совсем то.
А главное что при использовании той же черепашки для SVN я просто выбирал «Соmmit» для папки с исходниками, и получал список файлов которые будут закомичены, тут же для получения подобного результаты мы должны 1. Сделать check out всего репозитория 2. Перед комитом сделать реверт чекаута для неизмененных файлов. 3. Выделить те файлы которые нужно закомитить в данный момент в отдельный changelist. 4. Закоммититься.
И это хорошо когда сервер не далеко, а вот когда между рабочей машиной и сервером пол мира, и каждое действие заставляет тебя 20-30-40 секунд смотреть в монито в ожидании результата. Вот тогда оно начинает бесить.
С другой стороны нельзя не отметить, что шелвы очень удобны, например.
Мне например не хватает банальной функции создать файл патча. Я понимаю. что есть шелв, однако это не совсем то.
А главное что при использовании той же черепашки для SVN я просто выбирал «Соmmit» для папки с исходниками, и получал список файлов которые будут закомичены, тут же для получения подобного результаты мы должны 1. Сделать check out всего репозитория 2. Перед комитом сделать реверт чекаута для неизмененных файлов. 3. Выделить те файлы которые нужно закомитить в данный момент в отдельный changelist. 4. Закоммититься.
И это хорошо когда сервер не далеко, а вот когда между рабочей машиной и сервером пол мира, и каждое действие заставляет тебя 20-30-40 секунд смотреть в монито в ожидании результата. Вот тогда оно начинает бесить.
С другой стороны нельзя не отметить, что шелвы очень удобны, например.
1. Сделать check out всего репозитория 2. Перед комитом сделать реверт чекаута для неизмененных файлов. 3. Выделить те файлы которые нужно закомитить в данный момент в отдельный changelist. 4. Закоммититься.Вообще странно вы с Perforce работаете. Всё обычно делается гораздо проще. :)
1. Сделать check out папки/файлов
2. Настроить рабочий workspace с опцией «revertunchanged» и не надо ничего вручную ревертить
3. В отдельный changelist можно не выделять, всё можно сабмитить из default
Хотя может я просто не понял вашей задачи. Я с командной строкой работаю редко. Пользуюсь чаще P4V и интеграцией в IDE, плюс свои обёртки над p4 для нестандартных задач.
1. В чем вобще суть Check out? лишнее действие по факту.
2. Что вы имеете в виду в этом пункте. Может я действительно работаю с ним не правильно.
3. Выделять надо если коммитить планируешь не все файлы.
C другой стороны если я не ошибаюсь надстройка над ide(VS) умеет автоматически чекаутить файлы в момент их изменения, и соответственно потребность в чекауте отпадает сама собой и мы получаем привычную(как в других системах) схему работы. Однако утверждать тут я не возьмусь.
2. Что вы имеете в виду в этом пункте. Может я действительно работаю с ним не правильно.
3. Выделять надо если коммитить планируешь не все файлы.
C другой стороны если я не ошибаюсь надстройка над ide(VS) умеет автоматически чекаутить файлы в момент их изменения, и соответственно потребность в чекауте отпадает сама собой и мы получаем привычную(как в других системах) схему работы. Однако утверждать тут я не возьмусь.
«Check out» в Perforce нужен, чтобы сообщить системе (серверу) о том, что вы хотите изменить файл. Perforce не создаёт в workspace никаких метафайлов и метапапок, как это делают другие СКВ. Поэтому «Check out» нужен, иначе сервер просто не узнает о том, что файл был кем-то открыт на изменение. Да, интеграция в IDE обычно делает его автоматом при редактировании файла, и это очень удобно. :)
При создании Workspace вы можете задать опцию для него «revertunchanged», тогда при сабмите все файлы, которые были помечены как «Check out», но не были изменены, будут автоматически «зареверчены» и не будут зафиксированы. Это самая полезная и нужная опция. Не понятно, почему она не установлена по умолчанию.
Если вы сабмитите не все файлы, то просто укажите эти файлы и всё, только они будут зафиксированы. Остальные файлы в changelist останутся нетронутыми.
При создании Workspace вы можете задать опцию для него «revertunchanged», тогда при сабмите все файлы, которые были помечены как «Check out», но не были изменены, будут автоматически «зареверчены» и не будут зафиксированы. Это самая полезная и нужная опция. Не понятно, почему она не установлена по умолчанию.
Если вы сабмитите не все файлы, то просто укажите эти файлы и всё, только они будут зафиксированы. Остальные файлы в changelist останутся нетронутыми.
И вот тут мы видим проблему. Всегда нужен коннект к серверу, и коннект достаточно быстрый. Отсюда и растут по факту все недостатки для меня лично.
p.s. А вот опцию я не нашел…
p.s. А вот опцию я не нашел…
Редактирование Workspace в P4V
Ну а с сервером да, но тут всё же предполагается, что сервер где-то близко и/или доступен 24/7 в пределах сетки/VPN вашей компании. :)
Благодаря тому, что сервер VD подразделения Самсунга находится в штаб квартире, банальная загрузка очередной телевизионной прошивки в России длится несколько дней. Я уж молчу про отсылку изменений назад, когда создается по два соединения с сервером на каждый измененный файл… Думаю, мой случай далеко не единичный для географически распределенных команд.
У нас с вами даже сервера в одной стране расположены, только заказчики конкуренты. И канал внешний у Беларуси поменьше :)
И почему корейцы так любят Perforce?
И почему корейцы так любят Perforce?
Видимо потому что только в Perforce можно жестко требовать формат commit message (доходит до смешного), запрещать отменять уже созданные, но еще не отправленные правки (вообще полный бред) и создавать каждому программисту по персональному сандбоксу, в которых должна типа вестись реальная разработка. Ну и до кучи запрещать удаление веток и постоянно менять IP адрес сервера.
Товарищ, который уехал в Самсунг в Корею мне писал, что «идиотизма хватает», но я не думал, что до такой степени.
Мрак. У нас очень демократичные правила работы с сервером, например, можно редактировать commit message после фиксации. Запрет удаления веток – что за бред? История же всё помнит и всё можно увидеть на графе ревизий.
В общем, похоже в Самсунге серьёзные инфраструктурные проблемы. Только непонятно чем они вызваны в большей степени, маниакальным огораживанием или технической некомпетентностью ответственных за это дело корейцев?
Мрак. У нас очень демократичные правила работы с сервером, например, можно редактировать commit message после фиксации. Запрет удаления веток – что за бред? История же всё помнит и всё можно увидеть на графе ревизий.
В общем, похоже в Самсунге серьёзные инфраструктурные проблемы. Только непонятно чем они вызваны в большей степени, маниакальным огораживанием или технической некомпетентностью ответственных за это дело корейцев?
Если по уму, то для распределенных команд нужна децентрализованная СКВ, по-моему это вполне очевидно и зарекомендовало себя на практике. Perforce может работать в режиме Distributing, когда существует несколько серверов, и производится синхронизация между ними.
Я из вашего комментария не понял, у вас проблема в канале связи или проблема в работе сервера?
Я из вашего комментария не понял, у вас проблема в канале связи или проблема в работе сервера?
И в том и другом. Во-первых, канал у нас достаточно узкий (это еще ладно) и с высоким RTT (несколько сотен миллисекунд пинга это ооочень медленно). Во-вторых, сам по себе сервер чертовски медленный (на одной машине тысячи и тысячи пользователей). И в-третьих, корейцы я подозреваю что просто не в курсе таких умных слов как «режим Distributing» в своей маниакальной одержимости запрещать все что только можно. Комит локальный и то отменять запрещают. Я бы долго и смачно ругал их инфраструктуру и описывал причины этого «фрактала отсоса», но боюсь за свой NDA.
У нас ненавидят лютой ненавистью! И по слухам соседи по офису из NVIDIA тоже…
+1 Perforce, немного допиленный напильником. Ненавидеть его пока не вижу причин.
Использовали SVN перешли на Mercurial, потом начали использовать Git, сейчас переводим все проекты на него, для унификации.
На работы мы, благодаря приверженности решениям, «прошедшим проверку временем», до сих пользуемся PVCS, древнее которой только мамонты (первый релиз был в 1985 году, на год раньше CVS). Используется система потому, что она одновременно и простая в обслуживании, и тесно интегрирована с IDE (AMI Visual eBIOS 4). Как только AMI наконец добавят интеграцию с Git в VeB 5 — тут же на него и перейдем, но и выбросить PVCS не получится, пока последний проект на базе Aptio 4 не получит статус EOL, т.е. еще минимум лет 5-7. Вот такой вот энтерпрайз, позавчерашние технологии уже сегодня.
Встречаются и с системы контроля версий при помощи папок.
Я для своих проектов (и вообще для себя) перешёл с SVN и bazar на fossil:
- удобно, так как не требует инсталляции — скачал один файл и работай
- весь репозиторий в одном файле, можно бросить в DropBox и не думать о синхронизации или организации сервера
- DVS: удобно работать, если нет доступа к сети
- Встроенная Wiki: также решила проблему синхронизации/организации отдельного сервера
У veracity на редкость неинформативный сайт. Попытался посмотреть, не добавили ли они поддержку
Хотя после установки видно — всё же добавили. Только они единственные догадались зачем‐то после содержимого файла добавлять лишную новую строку, так что нельзя делать
Если что, то issue tracker’а нет, список рассылки закрыли, даже Q&A недоступен, поэтому пожаловаться разработчикам не представляется возможным.
(hg|bzr|svn|fossil) cat/git cat-file, а документации нет. И QA, где я видел (или задавал?) вопрос про эту возможность, недоступен.Хотя после установки видно — всё же добавили. Только они единственные догадались зачем‐то после содержимого файла добавлять лишную новую строку, так что нельзя делать
vv cat -rN foo.png > bar.png. И назвать это своё поведение «UNIX-style cat»! Впрочем, vv cat нельзя делать и по другим причинам: почему‐то изображение, на котором я проверял было обрезано с 189k до 1,4k.Если что, то issue tracker’а нет, список рассылки закрыли, даже Q&A недоступен, поэтому пожаловаться разработчикам не представляется возможным.
Раньше на работе был Hg, теперь все потихоньку переносят на Git, поставили Stash. Часть домашних проектов как на hg, так и на git'е. Думаю, в скором времени, совсем про hg забуду.
А почему с HG обратно на Git переходят? Вроде везде писали, что он круче, проще, баще. Git я думал используют только из-за github, для домашних проектов.
Мы не были на ГИТе, поэтому никакого обратно у нас не было. Так случилось, что нужно было выбрать одну систему для двух разных отделов, чтобы не поддерживать, на тот момент, отдельно hg и svn. Те, кто сидели на hg, в том числе и я, предлагали соседний отдел перевести с svn на hg, чтобы для нас ничего не изменилось, но решение делало руководство и они выбрали гит, так как он «немного быстрее». Ну а раз, помимо всего прочего, руководство решило подключить такую штуку как Stash и привязать к Jira, то мы только обрадовались.
не ну хостят же рабочие проекты на гитхабе. нет ведь?
Зато на гитхабе много либ, движков и прочего кода, который можно повторно использовать.
Хостят, естественно.
Не по теме: во время работы над проектом не всегда хочется опенсорсить (как принято в гитхабе), а приватный репозиторий стоит денежку. Благо, что для таких целей есть Bitbucket.
Не по теме: во время работы над проектом не всегда хочется опенсорсить (как принято в гитхабе), а приватный репозиторий стоит денежку. Благо, что для таких целей есть Bitbucket.
Хостят, разумеется. Иногда основной софтварный продукт компании открыт, часто выкладываются побочные проекты типа инструментов, плагинов, примеров и документации. Помимо этого есть приватные репозитории и целый приватный гитхаб (https://enterprise.github.com/).
Stash, думаю, это серьезно подкупает, если есть возможность его приобрести. Это тотже butbucket, только свой. Насколько мне известно, что-то приближенное к сташу Atlassian свернули и с hg, их проектов, остался только сам битбакет, который они купили.
> Вроде везде писали
Пишут евангелисты которых такое впечатление что у hg гораздо больше чем пользователей. А переходят те кто сравнил обе VCS в работе. Я вот тоже начинал с mercurial, но нашёл git гораздо более удобным, логичным и простым.
Пишут евангелисты которых такое впечатление что у hg гораздо больше чем пользователей. А переходят те кто сравнил обе VCS в работе. Я вот тоже начинал с mercurial, но нашёл git гораздо более удобным, логичным и простым.
… но нашёл git гораздо более удобным, логичным и простым.
Хм… Видимо, это сугубо персонально. Я тоже довольно долгое время работал и с Гитом, и с Меркуриалом, и у меня впечатления кардинально противоположные. На этой неделе, кстати, своим коллегам буду делать доклад про сравнение обоих систем :))) Стало быть, понятие удобства и локаничности у каждого своё.
На старой работе был TFS, но я от него остался не в восторге.
Для части проектов использовался древний CVS, чуть позже перешли на SVN.
Сейчас используем Git.
Для личных проектов также Git (BitBucket). Устраивает полностью.
Для части проектов использовался древний CVS, чуть позже перешли на SVN.
Сейчас используем Git.
Для личных проектов также Git (BitBucket). Устраивает полностью.
старые версии TFS да, были с «ньюансами». последние пару версий, в т.ч. 2013 и онлайн версия очень неплохи.
Например, TFS прекрасно интегрируется с MS Project для списка и контроля выполнения задач.
и 2013 и онлайн версия бесплатны для команды из 5 разработчиков. свой проект под патронатом BizSpark держу в облаке.
Другие и рабочие проекты держу в Git, потому как к Msft стеку они не относятся.
Например, TFS прекрасно интегрируется с MS Project для списка и контроля выполнения задач.
и 2013 и онлайн версия бесплатны для команды из 5 разработчиков. свой проект под патронатом BizSpark держу в облаке.
Другие и рабочие проекты держу в Git, потому как к Msft стеку они не относятся.
Использую CVS, встроенную в SAP ERP. Так себе.
На старой работе использовали CVS, потом переехали на SVN.
На новой используем собственную систему контроля версий, разработанную в ещё в 70-х. При этом она совмещена с SVN и Perforce.
На новой используем собственную систему контроля версий, разработанную в ещё в 70-х. При этом она совмещена с SVN и Perforce.
Ну нет такой системы контроля версия как TFS. Team Foundation Server это продукт полного Application Lifecycle Management в который входит две VCS, git и Team Foundation Version Control. Раз делаете опрос, то делайте его нормально, на техническом ресурсе всё таки.
<sarcasm>release_1.0.23_full_v2_final_edit_fix_final2.zip</sarcasm>
Git, конечно же.
Git, конечно же.
На работе используем свою систему контроля версий (которую и разрабатываем). Дома Git.
А зачем свою разрабатываете? Вот прям ни одна не покрывает потребности?
Она довольная старая и популярная и имеет некоторые преимущества перед другими. www.serena.com/index.php/en/products/featured-products/dimensions-cm/
По сути-то какие преимущества? Не нашёл в описании ничего уникального (в нём больше про свистелки и перделки, нежели про контроль версий).
Например то, что компания выплачивает компенсацию в случае утери данных :) Преимущества, в основном, в таком плане. +Очень гибкая система настройки доступа, разделение на инженеров/девелоперов/менеджеров и т.д.
Если нет реальных преимуществ, почему не использовать существующие VCS? Вон, Майкрософт и то принялась везде добавлять поддержку гита.
Настройка доступа, имхо, нужна, если делать всё через попу и пихать всё в один репозиторий. Хотя, может, я просто не работал в погрязших в бюрократии мегакорпорациях, где принято настраивать доступ к каждому файлу. %)
Настройка доступа, имхо, нужна, если делать всё через попу и пихать всё в один репозиторий. Хотя, может, я просто не работал в погрязших в бюрократии мегакорпорациях, где принято настраивать доступ к каждому файлу. %)
И как вам ClearCase? От нашего тимлида слышал положительные отзывы.
Я использовал на предыдущем месте работы в течение нескольких лет.
Моё впечатление — система морально устаревшая. Чего только стоят неатомарные коммиты, необходимость блокировки файлов для их изменения, а также отсутствие трёхстороннего merge!
Моё впечатление — система морально устаревшая. Чего только стоят неатомарные коммиты, необходимость блокировки файлов для их изменения, а также отсутствие трёхстороннего merge!
Интерфейс пользователя и удобство работы хуже, чем у CVS. Более неинтуитивной и неудобной системы никогда не видел. Требует отдельного сервера (в некоторых случаях, более чем одного) и отдельного администратора (или нескольких). Лицензия на разработчика стоит $5000. В принципе не могу понять людей, которые ее выбирают. Даже по сравнению с Subversion она выглядит как каменный топор в сравнении с плазмаганом.
Интересно, использует ли кто-нибудь Darcs…
Насколько я знаю, его используют в основном в Haskell среде.
В основном, но не только. Сам слышал о людях, не работающих с Haskell и использующих Darcs. Просто интересно, что ими движет.
Accurev!
Все-таки Perforce следовало бы добавить в список (в самом опросе)… буду знать :)
На работе использую RCS.
Гляжу на сложность современных систем контроля версий…
Слушаю фразы в духе «У меня все время открыт Repository Explorer, я в нем работаю»…
И все сильнее погружаюсь в ощущение, что VCS из инструмента превратились в проблему…
Наверно, это очень удобно на каждый чих делать коммиты… Но моя работа, как программиста, писать код, а не следить за ветвями, с кучей мелких коммитов…
Результатом моей работы является код, а не репозиторий.
Поэтому давно и надолго — SVN и коммиты только в ключевых точках.
Слушаю фразы в духе «У меня все время открыт Repository Explorer, я в нем работаю»…
И все сильнее погружаюсь в ощущение, что VCS из инструмента превратились в проблему…
Наверно, это очень удобно на каждый чих делать коммиты… Но моя работа, как программиста, писать код, а не следить за ветвями, с кучей мелких коммитов…
Результатом моей работы является код, а не репозиторий.
Поэтому давно и надолго — SVN и коммиты только в ключевых точках.
Все относительно в этом мире. У нас на одном проекте около 700 человек работало перед релизом, представьте если ктото будет коммитить раз в несколько дней. Продукт никогда не выйдет в свет.
оффлайн репозитории с постоянными коммитами никак эту проблему не решают.
ну и в целом, либо у вас работа этих 700 человек глобально не пересекалась, либо были огромные проблемы с архитектурой.
ну и в целом, либо у вас работа этих 700 человек глобально не пересекалась, либо были огромные проблемы с архитектурой.
Мелкие коммиты легче воспринимать и ревьюить. Чем быстрее код попадёт в транк, тем легче будет проходить мёрж и тем быстрее другие смогут воспользоваться результатами труда или найти ошибки.
Недостатки есть, но достоинства обычно перевешивают.
Например, в LLVM практикуется именно инкрементальный подход с минимумом веток и минимально возможными самодостаточными патчами. SVN этому на обычно не помеха, с фабрикатором работать достаточно удобно.
Недостатки есть, но достоинства обычно перевешивают.
Например, в LLVM практикуется именно инкрементальный подход с минимумом веток и минимально возможными самодостаточными патчами. SVN этому на обычно не помеха, с фабрикатором работать достаточно удобно.
Фабрикатор кстати да, спасает от засорения транка мелкими коммитами. Ревьюить-то их может и проще, но дергать патчи из такого репозитория или аннотейтить код спустя несколько месяцев/лет довольно утомительно.
Я вообще не очень люблю изменения и стараюсь, чтобы коммитов было поменьше, но пологичнее. :-)
Я вообще не очень люблю изменения и стараюсь, чтобы коммитов было поменьше, но пологичнее. :-)
Вы только пишете код, никогда его не отлаживаете, или скажем, тесты не прогоняете? VCS при этих действиях очень помогает. Найден баг: откат на чистый репозиторий — прогон тестов — поиск бага — один-два коммита — прогон тестов — push. Что вы без VCS делаете? На каждый чих сохраняете копию проекта для экспериментальных изменений и исправления? Особенно здорово, если поработали над багом до обеда, сделали что-то, вернулись — и где это мы остановились, что сделано? Смотреть рекурсивным diff по текущему проекту и скопированному чистому? Веселье.
Начал использовать Git на третьем курсе, никаких неудобств не испытываю. На работе его же применяем.
Начал использовать Git на третьем курсе, никаких неудобств не испытываю. На работе его же применяем.
В этом случае я использую SVN.
Речь не о том, что контроль версий не нужен.
Речь о том, что проект, в котором приходится отдельно серьезно прорабатывать структуру репозитория и правила коммитов, проект, в котором от VCS требуется больше чем Commit/Update/Diff — плохой проект. И решать проблемы надо не накручиванием функционала VCS, а пересмотром структуры проекта.
Речь не о том, что контроль версий не нужен.
Речь о том, что проект, в котором приходится отдельно серьезно прорабатывать структуру репозитория и правила коммитов, проект, в котором от VCS требуется больше чем Commit/Update/Diff — плохой проект. И решать проблемы надо не накручиванием функционала VCS, а пересмотром структуры проекта.
Это игра была, естестественное не все 700 были программистами, но все хранят данные в репозитории. Проблемы всегда есть, еще больше если ктото долго не заливает свои изменения.
UPD: не туда написал, ответ выше для AllexIn.
UPD: не туда написал, ответ выше для AllexIn.
Эх, в одной конторе приходилось пользоваться IBM ClearCase. Вот это кошмарный кошмарище, да еще и лицензия на одного пользователя стоит $5000.
Вообще не понимаю зачем другие системы, кроме как git. Он и работает намного бытсрее (так как локально, да) и удобен. И очень много возможностей есть, сразу и не разберёшься. Хотя основам быстро научится можно. Вот сходу например: git-scm.com/book/ru
Некоторые стронники svn говорят, что в git нельзя получить один файл/каталог из репозитория, не получив весь репозиторий.
Хотя сейчас может уже и можно.
Хотя сейчас может уже и можно.
Например, потому что в Git не самая умная работа с ветками: habrahabr.ru/post/123700/
Потому что, скажем, Mercurial лучше подходит для работы именно с кодом и текстами (при этом от так же быстр и локален): habrahabr.ru/post/168675/
Например потому что rebase — одна из самых кошмарно реализованных идей, но при этом часто используемая:
habrahabr.ru/post/179123/
habrahabr.ru/post/179673/
geekblog.oneandoneis2.org/index.php/2013/04/30/please-stay-away-from-rebase
Потому что в Git — кишки наружу и легче и непринуждёнее выстрелить себе в ногу и сломать репозиторий. Можно научиться это обходить, но ценой каких усилий? Да, у Git есть киллер-фича в виде Github и Линус Торвальдс в качестве евангелиста, которого иногда боготворят. Но это не самое лучшее решение именно для работы вместо дурных приключений (мне часто приходится работать и с git и с mercurial, знаю о чём говорю).
Возможно, вы перешли на git сразу с svn/cvs и не видели альтернатив. Но они есть и, как минимум, не хуже. :) Просто git стал стандартом де-факто и популярнее, к сожалению, как шансон. А популярность — не всегда признак качества, как и мнение толпы. :)
И да, я фанат mercurial. :)
Стреляйте. :)
Потому что, скажем, Mercurial лучше подходит для работы именно с кодом и текстами (при этом от так же быстр и локален): habrahabr.ru/post/168675/
Например потому что rebase — одна из самых кошмарно реализованных идей, но при этом часто используемая:
habrahabr.ru/post/179123/
habrahabr.ru/post/179673/
geekblog.oneandoneis2.org/index.php/2013/04/30/please-stay-away-from-rebase
Потому что в Git — кишки наружу и легче и непринуждёнее выстрелить себе в ногу и сломать репозиторий. Можно научиться это обходить, но ценой каких усилий? Да, у Git есть киллер-фича в виде Github и Линус Торвальдс в качестве евангелиста, которого иногда боготворят. Но это не самое лучшее решение именно для работы вместо дурных приключений (мне часто приходится работать и с git и с mercurial, знаю о чём говорю).
Возможно, вы перешли на git сразу с svn/cvs и не видели альтернатив. Но они есть и, как минимум, не хуже. :) Просто git стал стандартом де-факто и популярнее, к сожалению, как шансон. А популярность — не всегда признак качества, как и мнение толпы. :)
И да, я фанат mercurial. :)
Стреляйте. :)
О! какой подробный ответ! Вот только не понимаю зачем минусовать мой комментарий (это не именно к Вам, просто мысли вслух скорее) я высказала своё мнение, открыта вот к таким ответом, очень подробным и аргументированным. Что-то вроде дискуссии =)
Минусуют, скорее всего, сторонники других VCS.
ну логично =) Хотя могли бы рассказать плюсы своего выбора, достоинства =) ну их выбор =)
Ну как же. Рассказали :)
© JC_Piligrim
Например, потому что в Git не самая умная работа с ветками: habrahabr.ru/post/123700/
Потому что, скажем, Mercurial лучше подходит для работы именно с кодом и текстами (при этом от так же быстр и локален): habrahabr.ru/post/168675/
Например потому что rebase — одна из самых кошмарно реализованных идей, но при этом часто используемая:
habrahabr.ru/post/179123/
habrahabr.ru/post/179673/
geekblog.oneandoneis2.org/index.php/2013/04/30/please-stay-away-from-rebase
Потому что в Git — кишки наружу и легче и непринуждёнее выстрелить себе в ногу и сломать репозиторий. Можно научиться это обходить, но ценой каких усилий? Да, у Git есть киллер-фича в виде Github и Линус Торвальдс в качестве евангелиста, которого иногда боготворят. Но это не самое лучшее решение именно для работы вместо дурных приключений (мне часто приходится работать и с git и с mercurial, знаю о чём говорю).
Возможно, вы перешли на git сразу с svn/cvs и не видели альтернатив. Но они есть и, как минимум, не хуже. :) Просто git стал стандартом де-факто и популярнее, к сожалению, как шансон. А популярность — не всегда признак качества, как и мнение толпы. :)
© JC_Piligrim
Я подозреваю что минуса наставили в первую очередь за
Зачем нужны айфоны, если есть самсунги — сразу же понятно, что сейчас холивар начнется.
зачем другие системы, кроме как git
Зачем нужны айфоны, если есть самсунги — сразу же понятно, что сейчас холивар начнется.
Почти полностью согласен! Я, правда, практически не пользовался не-DVCS, начал сразу с git несколько лет назад. Помню, как с большим трудом и чтением мануалов получались в нём всякие вещи сложнее обычных коммитов — а потом попробовал mercurial. Там сразу как-то всё для людей сделано, один раз прочитал суть основных идей и дальше понятно. Ну и написана она на питоне, и расширения соответственно на нём обычно пишутся — удобно.
Приходилось (и приходится) администрировать на работе порядка сотни репозиториев git и пару-тройку hg. Типичный размер проекта — до 2-3 сотен тысяч строк. Все проекты под Linux. Специфика: околонаучный R&D, много младших программистов. По опыту:
1) В настоящий момент Git работает ощутимо быстрее при работе с удаленной копией. Ради эксперимента конвертировал mercurial проекты в git, время клонирования сокращалось примерно в полтора-два раза. С отправкой правок назад Гит также справлялся быстрее. В связи с этим недоумеваю по поводу бенчмарка скорости контроля версий, проведенным питонистами, когда они решали, где хранить свой Питон.
2) Локальные репы Mercurial периодически тупо портились нахрен. Уже не помню точно симптомы, по-моему hg сегфолтился. Это было бы смешно, если бы не так грустно: джуниоры теряли пару дней своей работы.
К слову, гит репы переживали даже file system corrupton, причем серьезный такой, с перетиранием последних файлов в .git мусором на рейде с ext4. git fsck/git gc/git fetch/git checkout с ручным удалением objects реально работает даже в запущенных случаях с отсутствующими комитами и прочими ударами судьбы.
3) Про «кишки наружу» — согласен. Но в ситуациях, когда «криво намержил/не так отребейзил/наворотил отнекомпетентностинезнания полный ахтунг в репе» git reflog спасал бесчисленное число раз. Просто откатывал к последней «точке восстановления» и все. Даже не заикайтесь про hg rollback при неизвестной серии косяков в истории).
4) Из-за своей большей распространенности у Гита все гораздо лучше с интеграцией в CI и шире выбор сервисного софта. Речь не об отсутствии/присутствии плагина в Jenkins, а о количестве настроек и интеграции с другими плагинами. Одних Git веб серверов столько, что не сосчитаешь. Любая ревью система умеет гит, но не всегда — mercurial. Просмотрщиков истории изменений у гита пруд пруди, для меркуриала в свое время еле выбрал. Реализаций клиента у гита есть как минимум два — С и Java (JGit), и это очень круто, так как куча серверов на Java умеют гит нативно.
Огромный плюс Mercurial — хорошая поддержка Windows. Вынужден признать, что у гита по-прежнему бесплатно с этим не очень.
1) В настоящий момент Git работает ощутимо быстрее при работе с удаленной копией. Ради эксперимента конвертировал mercurial проекты в git, время клонирования сокращалось примерно в полтора-два раза. С отправкой правок назад Гит также справлялся быстрее. В связи с этим недоумеваю по поводу бенчмарка скорости контроля версий, проведенным питонистами, когда они решали, где хранить свой Питон.
2) Локальные репы Mercurial периодически тупо портились нахрен. Уже не помню точно симптомы, по-моему hg сегфолтился. Это было бы смешно, если бы не так грустно: джуниоры теряли пару дней своей работы.
К слову, гит репы переживали даже file system corrupton, причем серьезный такой, с перетиранием последних файлов в .git мусором на рейде с ext4. git fsck/git gc/git fetch/git checkout с ручным удалением objects реально работает даже в запущенных случаях с отсутствующими комитами и прочими ударами судьбы.
3) Про «кишки наружу» — согласен. Но в ситуациях, когда «криво намержил/не так отребейзил/наворотил от
4) Из-за своей большей распространенности у Гита все гораздо лучше с интеграцией в CI и шире выбор сервисного софта. Речь не об отсутствии/присутствии плагина в Jenkins, а о количестве настроек и интеграции с другими плагинами. Одних Git веб серверов столько, что не сосчитаешь. Любая ревью система умеет гит, но не всегда — mercurial. Просмотрщиков истории изменений у гита пруд пруди, для меркуриала в свое время еле выбрал. Реализаций клиента у гита есть как минимум два — С и Java (JGit), и это очень круто, так как куча серверов на Java умеют гит нативно.
Огромный плюс Mercurial — хорошая поддержка Windows. Вынужден признать, что у гита по-прежнему бесплатно с этим не очень.
Огромный плюс Mercurial — хорошая поддержка Windows. Вынужден признать, что у гита по-прежнему бесплатно с этим не очень.Уточните?
Я наоборот плевался от того, что в Mercurial приходилось line-endings отдельно каждому пользователю выставлять, а в git настройки в репо хранятся (.gitattributes). Было это правда года два назад.
Я имел в виду, что GUI для гита под Windows действительно хорошие только платные. TortoiseGit использовать так проще сразу в консоли команды набирать, будет хотя бы понятнее и надежнее (и в перспективе быстрее). Есть еще гораздо более приятный клиент от Atlassian, его почему-то стало проблематично скачать, но ссылка на старую версию работает. А так у нас все виндузятники сидят на SmartGit.
TortoiseHG когда я им пользовался в последний раз был не в пример удобнее и прозрачнее. Не в курсе, есть ли другие неплохие бесплатные клиенты, подозреваю что есть.
TortoiseHG когда я им пользовался в последний раз был не в пример удобнее и прозрачнее. Не в курсе, есть ли другие неплохие бесплатные клиенты, подозреваю что есть.
TortoiseGit
А что с ним не так? Вроде всё что нужно для работы там есть…
...GUI для гита под Windows действительно хорошие только платные.SourceTree от Atlassian бесплатный. Его хвалят. А почему его проблематично скачать? Вроде есть большая кнопка «Download» на сайте, и она работает. Текущая версия 1.6.1. :)
А из платных клиентов вы что щупали?
У git есть две реализации на C: libgit2 (ещё не закончена, но по большей части работает; предназначена для использования в качестве библиотеки и иногда быстрее (т.к. не надо создавать новый процесс и не надо парсить его вывод), иногда наоборот (сам код библиотеки иногда медленнее, возможно сейчас частично или полностью исправили)) и привычный клиент git (но здесь уже не только C:
zyx …/c/vim-upstream/s 1 file --mime-type /usr/libexec/git-core/git* | sed 's/^\S*\s*//' | sort | uniq -c
129 application/x-executable
2 inode/symlink
6 text/x-perl
1 text/x-python
30 text/x-shellscript
Mercurial на питоне и поэтому гораздо неповоротливее.
Можете представить больше конкретики, в чём именно Mercurial гораздо неповоротливее? В интернете есть куча отчётов о сравнении производительности разных DVCS. Например, вот один из них. Там есть интересные моменты не в пользу Mercurial, но в целом картина не такая уж печальная.
Я в каком-то из постов по VCS уже писал об этом. Склонируйте репозиторий Mozilla Firefox и сделайте hg grep, к примеру, по слову «password». Эта операция адски медленно отрабатывает, в отличие от git grep по ядру Linux или Rust, к примеру. Мучительно смотреть. Я не говорю, что hg везде тормозной, я его не так много использовал. Но в данном случае он меня разочаровал.
externals пока по ощущениям самые удобные в svn.
как раз планировал уйти с svn на git или hg, в надежде получить более контролируемые externals, но там оказалось все еще хуже.
так что мирюсь с externals не привязанными к ревизии, зато они нормально работают.
как раз планировал уйти с svn на git или hg, в надежде получить более контролируемые externals, но там оказалось все еще хуже.
так что мирюсь с externals не привязанными к ревизии, зато они нормально работают.
В гит добавили же «отвязанные» субмодули, не?
в SVN externals можно не целый репозиторий пихать, а отдельный каталог.
А это уже от традиции SVN пихать всё в один репозиторий нужно избавляться.
А зачем?
Один из примеров использования externals:
делаем проект, в нем отдельный каталог tools, которым пользуются художники, моделлеры и проче артисты.
Сами по себе тулзы не являются частью проекта и используется в нескольких проектах, поэтому подключены как externals.
При этмо репозиторий с тулзами содержит как исходники, так и бинарники. И вот именно каталог bin подключен в виде externals к проекту.
Зачем мне тут несколько отдельных репозиториев?
Один из примеров использования externals:
делаем проект, в нем отдельный каталог tools, которым пользуются художники, моделлеры и проче артисты.
Сами по себе тулзы не являются частью проекта и используется в нескольких проектах, поэтому подключены как externals.
При этмо репозиторий с тулзами содержит как исходники, так и бинарники. И вот именно каталог bin подключен в виде externals к проекту.
Зачем мне тут несколько отдельных репозиториев?
А зачем?
А зачем иначе?
Я не вижу практических причин держать исходники и выходные бинарники в одном репозитории. Мне это видится жутко неудобным даже безотносительно системы контроля версий. Это же источник вечной рассинхронизации состояния. Я пуляю бинарники, а получаю устаревшую версию, потому что заливший исходники не перекомпилировал. Я коммичу сорцы, а мне в диалоге тонна мусора из бинарников, чёрт ногу сломит. Плюс репозиторий у SVN тоже не резиновый, он от запихивания тонны бинарников при каждом коммите распухнет и будет отвечать по полчаса. Зачем художников заставлять пользоваться SVN-ом для вытягивания тулзов — тоже вопрос открытый.
бинарники самые актуальные какие только могут быть, потому что залиты вместе с исходниками. то есть строгое соответствие.
А как художникам тулзы тянуть?
И зачем вообще заставлять художников отдельно тянуть тулзы?
Они в начале рабочего дня делают Update и имеют полностью актуальную версию проекта.
А у меня тонны мусора нет, потому что весь мусор изначально в игнор листе.
А как художникам тулзы тянуть?
И зачем вообще заставлять художников отдельно тянуть тулзы?
Они в начале рабочего дня делают Update и имеют полностью актуальную версию проекта.
Я коммичу сорцы, а мне в диалоге тонна мусора из бинарников, чёрт ногу сломит.
А у меня тонны мусора нет, потому что весь мусор изначально в игнор листе.
Конфигурируем сервер непрерывной интеграции, чтобы после успешной сборки проекта бинарники складывались в некоторое публичное место (ftp, http, расшаренная папочка — по вкусу; не систему контроля версий, потому что она избыточна, и от ней только тормоза). Настраиваем ежедневный/ручной запуск скриптика обновления на компах художников, который скачивает тулзы последней версии из публичного места. По вкусу настраиваем бэкапы публичного места (если кому-то есть дело до старых версий тулзов) и прочие свистелки и перделки. Имеем:
1. Кристально чистый и быстрый репозиторий.
2. Простые и быстрые коммиты без головной боли.
3. Художникам только кнопки нажимать надо.
4. Бинарники обновляются только при успешной сборке.
Правда что-то мне подсказывает, что сейчас я услышу, что CI не нужен, и вообще всё слишком сложно, всегда одного SVN хватало. :-)
То есть у вас каждый инструмент — это ровно один исполняемый файл? Ни динамических библиотек, ни конфигов, ни прочих зависимостей?
1. Кристально чистый и быстрый репозиторий.
2. Простые и быстрые коммиты без головной боли.
3. Художникам только кнопки нажимать надо.
4. Бинарники обновляются только при успешной сборке.
Правда что-то мне подсказывает, что сейчас я услышу, что CI не нужен, и вообще всё слишком сложно, всегда одного SVN хватало. :-)
А у меня тонны мусора нет, потому что весь мусор изначально в игнор листе.
То есть у вас каждый инструмент — это ровно один исполняемый файл? Ни динамических библиотек, ни конфигов, ни прочих зависимостей?
CI не нужен, и вообще всё слишком сложно, всегда одного SVN хватало.
Сервер непрерывной интеграции конечно же нужен. Для основного проекта. Задача сервера в первую очередь обеспечить процесс тестирования проекта. Тулзы нафига в него пихать? Они меняются не так часто, полномасштабное тестирование им не нужно. Не вижу ни одного плюса в том, чтобы всякую мишуру в такой процесс запихивать.
То есть у вас каждый инструмент — это ровно один исполняемый файл? Ни динамических библиотек, ни конфигов, ни прочих зависимостей?
Библиотеки как правило не меняются, а значит при commite не светятся.
Конфиги никто со времен висты не хранит рядом с бинарниками — они все уникальны для каждого пользователя и хранятся в Май доках.
Отдельно мне интересно, как у вас выглядит обновление тулзы по запросу артиста… :)
У нас просто: запрос, изменение, Commit, Update
Задача сервера в первую очередь обеспечить процесс тестирования проекта.
И таки собирать и раздавать собранный проект, внезапно. en.wikipedia.org/wiki/Continuous_integration#Make_it_easy_to_get_the_latest_deliverables
Тулзы нафига в него пихать?
Их наличие на сервере сборки чем-то мешает?
Не вижу ни одного плюса в том, чтобы всякую мишуру в такой процесс запихивать.
Я выше четыре перечислил.
Отдельно мне интересно, как у вас выглядит обновление тулзы по запросу артиста… :)
У нас просто: запрос, изменение, Commit, Update
В этом процессе ничего не изменилось, только программисту не нужно коммитить бинарники, а художнику нужно тыкать по скрипту вместо дёрганья VCS.
Но вообще я вашу позицию понял:
Я выше четыре перечислил.
Ну ок, давайте по пунктам:
1. Кристально чистый и быстрый репозиторий.
По поводу скорости:
У меня нет опыта работы с 100 гиговыи репами… Наш 8 гиговый обрабатывается секунд 5. Намека на тормоза нет. Судя по инету — SVN начинает тормозить на репах от 20 гигов. 20 гигов даже с учетом контента надо постараться нафигачить. :)
Чистота — вопрос спорный. От того что в репозитории появилось несколько новы каталогов он грязнее не стал.
2. Простые и быстрые коммиты без головной боли.
Неужели добавление бинарника в репу на это как-то влияет? :)))
3. Художникам только кнопки нажимать надо.
А в приведенном у меня примере они еще что-то должны нажимать?
4. Бинарники обновляются только при успешной сборке.
Аналогично и при хранении в SVN. Там лежит всегда работающий бинарник. В условиях простых тулз он еще всегда и самый актуальный, потому что собран самим программистом. При этом ничего не мешает добавить файлик, если уж очень хочется в ежедневную сборку. Правда смысла не видно.
Так что повторюсь:
Не вижу ни одного плюса в том, чтобы всякую мишуру в такой процесс запихивать.
Выше перечисленные пункты более чем спорные и ИМХО недостаточны чтобы огород городить.
Вы приспособили инструмент под то, для чего он не предназначен по определению. Ну поздравляю.
Если вам нравятся многосекундные задержки, хлам в репозитории, дополнительные правила при коммитах и прочий геморрой — на здоровье. Если для вас добавления пунктика на сборочном сервере и скрипт в три строчки видятся несусветным огородом — на здоровье.
Вам с вашей философией гит вреден, продолжайте пользоваться свн. Вместо багтрекера советую эксель в тот же репозиторий запихать, вам понравится: очень удобно, минималистично, всем понятно, и ничего настраивать не надо. И для виртуалок лучшего места для хранения не найти: вся история хранится, всем доступно, можно форкаться. Ляпота.
Если вам нравятся многосекундные задержки, хлам в репозитории, дополнительные правила при коммитах и прочий геморрой — на здоровье. Если для вас добавления пунктика на сборочном сервере и скрипт в три строчки видятся несусветным огородом — на здоровье.
Вам с вашей философией гит вреден, продолжайте пользоваться свн. Вместо багтрекера советую эксель в тот же репозиторий запихать, вам понравится: очень удобно, минималистично, всем понятно, и ничего настраивать не надо. И для виртуалок лучшего места для хранения не найти: вся история хранится, всем доступно, можно форкаться. Ляпота.
Ну отлично, вместо аргументов пошло «сам дурак». :)
Я обозначил конкретные задачи и их решения. Объяснил, почему ваши доводы не актуальны… Странный у вас способ ведения диалога.
Где тут сказано что она не предназначена для работы с бинарниками и контентом?
Я обозначил конкретные задачи и их решения. Объяснил, почему ваши доводы не актуальны… Странный у вас способ ведения диалога.
Система управления версиями (от англ. Version Control System, VCS или Revision Control System) — программное обеспечение для облегчения работы с изменяющейся информацией. Система управления версиями позволяет хранить несколько версий одного и того же документа, при необходимости возвращаться к более ранним версиям, определять, кто и когда сделал то или иное изменение, и многое другое.
Где тут сказано что она не предназначена для работы с бинарниками и контентом?
1. Вы не назвали ни единого преимущества своего решения кроме «мы так привыкли» и «нам так проще».
2. Из недостатков моего решения вы назвали только «зачем городить огород».
3. Все преимущества моего решения вы покрыли «а нам и так неплохо живётся».
В таких условиях содержательный спор невозможен. С таким подходом я могу доказать преимущество «project.bak.zip» над любой VCS (и экселя над багтрекером).
К слову, основное преимущество моего подхода — это поддержка Git. Как я вижу, удобство и перфекционизм — слова для вас незнакомые, так что можете хоть на это обратить внимание.
2. Из недостатков моего решения вы назвали только «зачем городить огород».
3. Все преимущества моего решения вы покрыли «а нам и так неплохо живётся».
В таких условиях содержательный спор невозможен. С таким подходом я могу доказать преимущество «project.bak.zip» над любой VCS (и экселя над багтрекером).
К слову, основное преимущество моего подхода — это поддержка Git. Как я вижу, удобство и перфекционизм — слова для вас незнакомые, так что можете хоть на это обратить внимание.
1. Вы не назвали ни единого преимущества своего решения кроме «мы так привыкли» и «нам так проще».
Назвал.
Отдельно мне интересно, как у вас выглядит обновление тулзы по запросу артиста… :)
У нас просто: запрос, изменение, Commit, Update
И там вопрос, кстати, было бы интересно услышать как это делается у вас.
2. Из недостатков моего решения вы назвали только «зачем городить огород».
Это не правда.
В кратце:
1) Скорость не страдает, термин «чистота» не раскрыт.
Где здесь «нам так удобнее»?
2) Сложность коммита не раскрыта.
3) Сложность использования вашего и нашего решений не отличается. Хотя я по прежнему не понимаю как у вас решение работает, т.к. на вопрос заданный выше вы не ответили.
4) Утверждение не верное, там и так корректный бинарник. Причем утверждение основано на противопоставлении, а оно не обязательно должно быть.
И вот как итог уже: зачем огород городить? ради этих 4 пунктов, которые практически не имеют под собой оснований?
К слову, основное преимущество моего подхода — это поддержка Git.
То есть вы на полном серьезе строите структуру проекта под инструмент? :)
Ну так я о том и говорю — результатом работы сейчас становится красивый репозиторий, вместо кода.
У нас во главе угла проект, а не инструменты, и по этому мы смотрим на инструменты удовлетворящие наши нужды, а не нужды под инструмент подстраиваем.
И там вопрос, кстати, было бы интересно услышать как это делается у вас.
habrahabr.ru/post/233935/#comment_7896051
Это не правда.
Вы перечисляете не недостатки моего решения, а неубедительность для вас преимуществ.
Утверждение не верное
И билды у вас никогда не ломаются, ага.
То есть вы на полном серьезе строите структуру проекта под инструменте?
У разных инструментов разные возможности, достоинства и недостатки. Тащить личные привычки в любой инструмент — глупость.
Если вам нравится хранить недельные изменения без коммитов, целый день резолвить конфликты при мерже бранчей, тратить время на вазимодействие по сети, совокупляться с битыми данными — пожалуйста, используйте SVN, не могу вам запретить.
Мы в этой ветке тоже немного затронули эту тему, но там как-то нормальной дискуссии не получилось.
У меня есть и за и против хранения бинарников в репозитории. Мне кажется тут уж очень сильно все зависит от того, что вы разрабатываете и как.
1. Если вы сами пишите эти тулзы или библиотеки, а так же у вас есть возможность собрать любую версию в любое время — не стоит их запихивать в репозитории проектов. Пишите скрипты. То есть согласен с вами в этом случае.
2. Если вы пишите сервис, вам не нужно поддерживать 2х годовалые версии вашего продукта, вы легко переходите на новые версии библиотек. Опять же, не стоит складывать чужие бинарники к себе в репозиторий. Просто нет смысла.
3. Если вы пишите свой собственный продукт, вам необходимо поддерживать 2х годовалые проекты — в этом случае просто необходимо хранить где-то эти самые чужие зависимости. Так как вы просто не знаете, будет ли тот сайт, где вы скачали библиотеку существовать через 2 года или нет. Хранить их просто где-то — нужно делать бекапы, писать какие-то скрипты, которые бы как-то делали mapping вашей текущей версии из определенного branch на определенные версии этих библиотек. А можно сделать проще — положить все библиотеки в сам branch и больше никаких проблем — есть 1-1 mapping, есть история, знаете когда и что обновляли, а так же в любой момент времени можете собрать текущую версию. Если кто-то сломал этот самый build script, то он сломан в одном branch, а не для всей компании. Прикиньте, например, как бы вы это поддерживали, если бы у вас было, например, 200 разработчиков в компании с 20 branches.
У меня есть и за и против хранения бинарников в репозитории. Мне кажется тут уж очень сильно все зависит от того, что вы разрабатываете и как.
1. Если вы сами пишите эти тулзы или библиотеки, а так же у вас есть возможность собрать любую версию в любое время — не стоит их запихивать в репозитории проектов. Пишите скрипты. То есть согласен с вами в этом случае.
2. Если вы пишите сервис, вам не нужно поддерживать 2х годовалые версии вашего продукта, вы легко переходите на новые версии библиотек. Опять же, не стоит складывать чужие бинарники к себе в репозиторий. Просто нет смысла.
3. Если вы пишите свой собственный продукт, вам необходимо поддерживать 2х годовалые проекты — в этом случае просто необходимо хранить где-то эти самые чужие зависимости. Так как вы просто не знаете, будет ли тот сайт, где вы скачали библиотеку существовать через 2 года или нет. Хранить их просто где-то — нужно делать бекапы, писать какие-то скрипты, которые бы как-то делали mapping вашей текущей версии из определенного branch на определенные версии этих библиотек. А можно сделать проще — положить все библиотеки в сам branch и больше никаких проблем — есть 1-1 mapping, есть история, знаете когда и что обновляли, а так же в любой момент времени можете собрать текущую версию. Если кто-то сломал этот самый build script, то он сломан в одном branch, а не для всей компании. Прикиньте, например, как бы вы это поддерживали, если бы у вас было, например, 200 разработчиков в компании с 20 branches.
outcoldman
Вы рассматриваете нормальный случай использования бинарников в репозитории. Когда библиотеки, используемые в проекте, лежат вместе с ним — это нормальное решение, это «бинарные исходники». Как вы уже сказали, есть плюсы и минусы.
AllexIn же предлагает хранить в репозитории не библиотеки, а результаты сборки проекта. То есть вот исходники, а вот в том же репозитории рядом лежит исполняемый файл, собираемый из них. И при каждом коммите нужно коммитить и то, и другое.
Вы рассматриваете нормальный случай использования бинарников в репозитории. Когда библиотеки, используемые в проекте, лежат вместе с ним — это нормальное решение, это «бинарные исходники». Как вы уже сказали, есть плюсы и минусы.
AllexIn же предлагает хранить в репозитории не библиотеки, а результаты сборки проекта. То есть вот исходники, а вот в том же репозитории рядом лежит исполняемый файл, собираемый из них. И при каждом коммите нужно коммитить и то, и другое.
Мне кажется, что именно для быстрого обучения, без лишних подробностей, которые на начальном этапе и не нужны, отлично подходит githowto.com/ru. Git-scm всё же чуть более фундаментальный.
Иное (просьба указать в комментариях что именно)
Для работы ClearCase ибо «так надо». Даже не сам Clearcase, а специально созданные обертки вокруг него.
Для работы используем Perforce. Бесплатную версию на 20 пользователей.
На работе используем и Perforce и TFS (есть p4-tfs синхронизация). Почему обе одновременно? Долгий рассказ о белках-истеричках. Дома (для себя) использую git, раньше mercurial. На git перешёл из любопытства, в своё время.
monotone
Мужики! Хелп! Я работаю в очень многообещающей компании, но они тут используют StarTeam CVS от Borland. (кто-нибудь про нее вообще слышал?). Как наставить компанию на путь истинный?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Опрос по системам контроля версий