Ответ: Толстая оперативка
 

svn никто не использует уже давно.
А тот же mercurial и git давно делают один архив до скачивания или загрузки.
А вот всякие package manager'ы тут да, например в больших проектах на python'е или node.js, когда у тебя куча зависимостей от библиотек, pip или npm требуется очень долго их качать с кучи мест, и потом половину ещё компилировать. Вот тут разница может быть хорошей.
Но имхо, там размер мелкий, и bottleneck'ом является сам HTTP запрос, нежели IO жёсткого.

Ответ: Толстая оперативка
 

А я использую Asset Server юнитивский. Кидайте свои камни.

Ответ: Толстая оперативка
 

Я никто, знающий, некоторое количество никого коих довольно нисколько

Ответ: Толстая оперативка
 

Мы на работе его постоянно юзаем. Так что ты - ещё не все.

Ответ: Толстая оперативка
 

Вы западная Европа, а там почти ничего мирового дельного не создаётся. А те кто и что-то создают, давно на git'ах. Ну вам с вашей ямки виднее.

Ответ: Толстая оперативка
 

Ответ: Толстая оперативка
 

Что в твоём понимании дельное?

Ответ: Толстая оперативка
 

moka скатывается в пафос раннего Mr_F_.
Мы тоже на работе (средняя конторка) используем svn и черепаху в качестве клиента. Вообще, спор об инструментах очень глупый. Лучше давайте оперативку обсуждать.

Ответ: Толстая оперативка
 

Ну возьмём стартапы последних несколько лет, назови мне мирового уровня продукты мобильные или веб, разработанные руссскими разрабами, и мы напишем им эмайл и спросим, они svn или git/mercurial используют.

Обсуждение систем контроля версий - очень увлекательное занятие, т.к. те кто понимают как они работают, и все сложные схемы взаимодействий в больших командах, требует хороших мозго-напрягов.
Но вы правы, "не будем скатываться" в дельные дискуссии, а лучше поболтаем о всем необходимой ОЗУ!

Ответ: Толстая оперативка
 

Макс, ты лучше напиши чем конкретнее (github / mercurial) лучше svn.

про ОЗУ была другая тема. эта тема теперь про системы контроля версий.

Ответ: Какая система контроля версий лучше (Battle!)
 

Не знаю насчет последних нескольких лет или мобильности, но Лаборатория Касперского компания мирового уровня.
Я думаю они в теме.
Так что можешь у них спросить =)

Ответ: Толстая оперативка
 

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

Ответ: Толстая оперативка
 

Тут даже думать нечего... - пиши мелко-мягким.

попытка вброса говна на вентилятор?

Ответ: Толстая оперативка
 

ололо, илита в треде, все быстро в бункер на колени

Ответ: Какая система контроля версий лучше (Battle!)
 

Данные сравнения уже много раз приводили.
Основные плюсы это децентрализованность каждого репозитория, и возможность хорошо организовать систему бранчей (по фичам, версиям, релизам, дев/лайв). Merge'ить вообще просто в git а в mercurial ещё меньше конфликтов выходит.
Если большая команда и бранчи между собой переплетаются, то в svn это геморой, когда в git'е всё просто, главное не забывать rebase'иться если зависимый бранч уходит вперёд по истории.
В командах по 30 человек на один проект, svn - это жопа.
Также интеграция со всякими Jira, и самим github/bitbucket - просто сказка.
Сравнения давно за нас провели, читайте в гугле:
http://stackoverflow.com/questions/8...han-subversion

Видимо ты не работал в команде более 1-3 человек.
Вот когда поработаешь с 5+ людьми над одним проектом, а ещё пару человек удалённо, то тогда и поговорим, ок?
О перфекционизме речи не идёт. Речь о минимализации отвлечений от самого написания кода, а всякие agile панели (jira) и системы контроля версий могут очень много времени отбирать.
Многие компании даже практикуют такую тему как Kaizen Friday - это раз в несколько недель, один день (пятница) выделяется полностью на систематизацию и удобство условий работы. Например deploy скрипты, чтобы не тратить время вручную деплоить, и системы контролей или всякие скрипты по ситуации.
Ты поработай в маломальски гибких условиях стартапов, тогда будет видно.
Если я заблуждаюсь о твоём опыте работы в командах, то будь добр поделись.

Ответ: Какая система контроля версий лучше (Battle!)
 

Хорошо ты победил :)

30 человек это не команда а банда :) команды это 7+-2.

Но про какие команды ты говоришь, если судя по твоим высказыванием ты похож на обычного индивидуалиста. Что ты будишь делать если в вашу группу придет человек который до этого с jit не работал. Ты ему скажешь, что ты неудачник, я не буду с тобой разговаривать, сиди в своей яме? xD
Возможно вам нужно просто перестроить процесс, чаще синхронизироваться между собой и вопросы о конфликтах между версиями отпадут сами собой? Удаленная разработчики это уже не команда, а внешние связи. А реально крутые продукты создают именно слаженные команды.

Ответ: Какая система контроля версий лучше (Battle!)
 

Какая система контроля версий лучше?
Которая выполняет поставленные перед ней задачи!

Ответ: Какая система контроля версий лучше (Battle!)
 

30 человек - это банда согласен, но обычно разбитая на команды по пица-на-команду (5-10), и далее взаимодействуют между собой и часто работают над общими проектами. Например когда на 5 команд одна система deploy'я, где общий репозиторий скриптов. Или например все зависят от какой-то utils js библиотеки, и каждому нужно туда что-то пихнуть/отредактировать. Или другая внутренняя разработка для компании (библиотеки). Примеров куча.

Я работал в компании где примерно 70 разработчиков, и три офиса по миру. Разбитые на команды 5-10 человек.
Также работал один с кучей дизайнеров, и сейчас в команде 5 человек, с двумя удалёнными разработчиками.

Ты имел ввиду git? Если мы кого и наймём, то человека гибкого, и если он работал хоть с одной системой контроля версий, то ему будет легко адаптироваться.
Я с mercurial не работал до текущей позиции, и мне один раз показали то как branch'ят в команде у них используя mercurial, и как merge'ат, после этого никаких проблем. Просто запомнить аналогию команд с другими системами. Единственное что проще это количество конфликтов минимализируется в mercurial, т.к. там обычно не merge'ат в branch с master'а, так история в default (master) branch'е будет чистой.

Детский сад.

Большинство проблем решается пересмотрением логики branch'ей и правилами что куда merge'им и как кооперируемся. Но не все системы контроля версий позволяют достаточно гибкости.

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

Нету одного пути делать что-то "реально крутое". Ты хочешь сказать тот же github не "реально крут"? (только давай объективно, если не пользовался им достаточно, отметь это, не стоит судить без опыта).

Теперь давай пиши что типо я сторонник удалённой работы (лол) и т.п. Любопытно как читая мои посты, "некоторых" клонит в обратную сторону, "если я не поддерживаю идею работы только в офисе, то я сторонник только удалённой работы."....

Бля смешные.
Давай radiobutton померимся фалосами, историей коммерческого опыта? ;)

Ответ: Какая система контроля версий лучше (Battle!)
 

Ходил тут на курсы международной компании РЕКЛАМЫ_НЕ_БУДЕТ, нам сделали репозиторий svn, дабы мы туда пихали свой, мега код, а там его будут менторить и опускать. Дык вот. Руководствовались тем, что будет проще, однако к концу курса таки решили что следующих студентов пустят на git, ибо как-то в свн не то и бывали необъяснимые косяки в разграниченном на всех репозитории. Вообщем магия и конкретные причины не особо присутствуют. Но видимо перспективность играет роль.

Ответ: Какая система контроля версий лучше (Battle!)
 

radiobutton, ты таки опытом своим не поделился, ведь яро выстаивал свою позицию, у тебя есть конкретные аргументы в пользу svn против git или mercurial, так поделись, может я заблуждаюсь.

Поделись опытом.

Ответ: Какая система контроля версий лучше (Battle!)
 

ну раз уж холиваар...
2Moka
хз как он, а я работал.
и с 5ю и с 50ю, и в продуктовой компании и в бл*цком аутсорсе. Давай поговорим :)
смело заявляю - кроме пафоса с твоей стороны в треде ничего полезного и осязаемого.
заявлять о придуманных тобой лидерах, новых стартапах и других продвинутых ребятах не использующих SVN - критинизм. Я только со старой работы интёрнал проектов на сабвершене десяток вспомню. И ничо так, успешных, связь, коммуникации, все дела. На текущей работе вот тоже svn, и ребят мы подбираем (по квалификации) годами. Мы просто ещё не знаем, но аналитик moka уже убеждён, что мы развалимся, из-за отсутствия git.

На деле уже правильно заметили: выполняет поставленные задачи - збс.
Лично я давным давно полюбил svn и не без труда пересел на git. Не жалею и признаю достоинства git и применяю его намного чаще чем тот же svn. Только вот не надо говорить, что из-за его превосходства, сабвершн умирает. Вовсе нет, это только твои домыслы.
Я тебе просто напомню, что гибкость зачастую сильно упрощает процесс растреливания конечностей. И вот очень умиляют ребята, говорящие какой гит крутой и классный, про легковесные бранчи, распределённые репы, а сами не представляют как и в каких случаях это применять. В итоге в клёвых коммандах с гибкими девелоперами в проектах на том же гите видим занимательнейшие архитектуры, вида "бранч на версию" с очерёдными коммитами в мастер. И не надо мне ляля, что "это надо просто эта самое как его уметь и быть гибким". Хочешь крутой и гибкий инструмент - плати. И за поиск вменяемого инженера, и за его зарплату, или за обучение дибила.
С свн-ом сложней себе прострелить конечности, хотя и возможностей бывает недостаточно. Гит гибче и сложней. Клиркейс ещё есть, та ещё дичь, достойная отдельного треда. Везде свои компромисы, а твои громкие односторонние заявления - показатель дилетантности. :)

P.S.: все переходы на личности - намеренные!

Ответ: Какая система контроля версий лучше (Battle!)
 

Ты меня не понял. Я не говорил что svn круче git и наоборот. Я проповедую, что нужно сосредотачиваться на самом продукте, а не на средствах достижения целей. Некоторым может хватить нажатия 2 кнопок в скв раз в несколько дней, при этом они будут получать удовлетворение от работы и делать хороший продукт.

Кстати про историю коммерческого опыта. Приходят на собеседования часто люди с 3+ летним опытом, не знающие начальных вещей, и с совершенным отсутствием логики. Так что для меня опыт это ниочем.

Ответ: Какая система контроля версий лучше (Battle!)
 

опытом просиживания штанов, а опыт работы в своей сфере, это всегда плюс..

Ответ: Какая система контроля версий лучше (Battle!)
 

Я себя снова процитирую если что:
Любопытно как обсуждение на определённую тему "система контроля версии", мы всё же умудряемся думать что это единственный "ингредиент" успеха.
И основываясь такому убеждение, далее судим другого, что он думает - это "единственное" что нужно для успеха.
Люди книги пишут, и покрывают только детали о успехе в разных сферах. А тут по 5 моим постам, меня уже наизусть "знают" - молодцы ребята ;)

Давайте придерживаться теме: Система Контроля Версии.
Обсуждение их различий, и удобства.

Другие факторы успеха команд можно обсудить в другом месте, они и рядом не сравниваются с топиком тут.

Можно и вообще без подобных систем, и в 5ом писать что-то нев**бенное, а можно и с самой подходящей по условиям системой, писать полное дерьмище и тратить 20% времени разработки тупо тра**ясь с системой контроля версий, то это git, svn, mercurial или ещё чё.


А что мне нужно расписывать конкретные детали по git'у и svn'у? Об этом писали уже много и достаточно. Моя идея донести факт того, что есть много систем, и стоит знать их особенности, для возможности адекватного выбора наиболее подходящей по условиям и требованиям бизнеса.

На чём основывается убеждение?
Да ты просто открой требования для новых работников на том же reed.co.uk или каком западном сайте, да там svn будет только в старых компаниях либо в очень жёсткой иерархии.
Везде git будет как минимум в 2 раза больше упоминаться. И если посмотришь описания работ, то сразу различается где не опытный агент писал описание - чаще svn. Проведи мелкий 5 минутный ресерч.

без комментариев.

Ну ты меня в ту же гребёнку так не сливай.

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

Да в том и дело, что я крикнул один раз, а далее меня уже не слышат.
Самый прикол, если посмотреть со стороны на "сторонников" svn, то отлично различается "упорство против всего что не svn" - это же очевидно. Вот погляди видео отличное на эту тему, как многие упирались новым и простым вещам. Дело в том что они даже не рассматривают вариант нового, т.к. проблем в жизни много, и бояться дёргаться - "там же больше проблем!", следственно это "парализует" кучу людей, оставляя их на дерьмоработах, работая в индустрии где тебя натягивают сверху, а твои мелкие проблемы в команде - решать никто не поспособствует - всё сам. Так вот в "нормальных" компаниях, люди с работы ходят после работы или время от времени как друзья в бары и например на картингах покататься, т.к. люди заинтересованы как в решении рабочих/бытовых отношений, так и в более слаженной работе и прогрессу вместе как команда.

Талк, про упоротость на старом перед новым (asm > fortran):
https://www.youtube.com/watch?v=8pTEmbeENF4


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


Расскажите мне ещё про меня, так любопытно!


кэп, и кому ты это проповедуешь, сам себе? Т.к. мне эта "проповедь" очевидна как 2+2.

Я и по 5+ встречал полная лажа. Да большинство всех консультантов - разрабы с 5+ годами опыта и дерьмо полное у них в голове почти всегда.
Меня интересует твой опыт как разработчика, от тебя лично, как ты своим временем распоряжаешься, где какие достижения/сложности преодолеваешь.
Года не решают, как и возраст, и качества не определяют. Разнообразие и желание развиваться - решает. Вот им и поделись.

Ответ: Какая система контроля версий лучше (Battle!)
 

304 Svn jobs
289 Git jobs
36 Mercurial jobs

для сравнения на hh.ru (выборка по IT):
svn: Найдено 272 вакансии
git: Найдена 441 вакансия
mercurial: Найдено 79 вакансий

Ответ: Какая система контроля версий лучше (Battle!)
 

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

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

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

Ответ: Какая система контроля версий лучше (Battle!)
 

Эт чо получается, в России компании попродвинутее будут? :-D

Ответ: Какая система контроля версий лучше (Battle!)
 

Хоть кто-то дельное что-то написал.
С историе у git'а порой да проблемки, тут mercurial получше справляется.
А переименование и перемещение файла нужно осуществлять git mv командой, т.к. просто так он "не сообразит угу".

reed.co.uk
svn - 319
git - 542 (+70%)
mercurial - 40

monster.co.uk
svn - 341
git - 604 (+77%)
mercurial - 40

careers.stackoverflow.com
svn - 48
git - 260 (+452%)
mercurial - 15

А теперь самое главное - Google Search Trends
http://www.google.co.uk/trends/explo...rcurial&cmpt=q
Даже в России. Тут комментарии излишни.

Ответ: Какая система контроля версий лучше (Battle!)
 

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

Ответ: Какая система контроля версий лучше (Battle!)
 

странно, вчера у меня другие цифры. видимо где то накасячил.

Ответ: Какая система контроля версий лучше (Battle!)
 

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

Ответ: Какая система контроля версий лучше (Battle!)
 

Я использую git в NetBeans, команды встроены в IDE - удобно.

Была однажды проблема: сначала у меня была папка с ресурсами, затем я её запаковал в 1 файл, название сделал такое же как у прежней папки.
При возврате на предыдущее состояние возник конфликт, который я объясняю тем, что винда не терпит в одном месте файл и папку с одинаковым именем - значит git сначала попытался скопировать прежнюю папку и не смог, но при этом удалил пак-файл.
В итоге ни папки ни пака - заново делал.
Может я что-то сделал не так, тогда только начал использовать git, но хз. После этого случая некоторое время перед checkout'ами делал копию папки .git - мало ли чё! :)

ПС1: Мне нравится возможность задать тэг (tag) для текущего состояния, свои релизы помечаю тегами.

ПС2: Проверил только что на тестовом проекте случай с одноимёнными файлом и папкой.
1. создал папку, сделал commit, сделал тэг для текущего состояния
2. удалил папку, положил файл с именем папки, сделал commit
3. сделал checkout первого commit'a по тегу
4. увидел свою папку из первого commit'a, обрадовался что всё работает
5. сделал checkout второго commit'a
6. не увидел свой файл, огорчился
7. снова сделал checkout первого commit'a
8. не увидел папку. опечалился
Выходит, теперь у меня нет ни файла ни папки, сколько не прыгай по commit'ам.

Мне git ничего не сказал про невозможность копирования или ещё что-то в этом роде, и лог без ошибок.


Если есть решение, то поделитесь.

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

Ответ: Какая система контроля версий лучше (Battle!)
 

Если по пути разработки ты делаешь архив всей директории чтобы хранить её как backup, то git для этого не рекомендуется. Создавай архив, и игнорируй его в git'е, и заливай куда-то ещё.
git - это не хранилище, а система контроля версий как и любая другая.
Плюс почему наименование архива должно совпадать с наименование директории?

Ответ: Какая система контроля версий лучше (Battle!)
 

>> архив всей директории чтобы хранить её как backup

не, это способ хранения версий без системы контроля ))

Суть проблемы покороче:

1. Папка - произвольная папка с ресурсами проекта (н-р gfx).
- существует в коммите №1, перед вторым коммитом заменяем её на файл

2. Файл - любой файл без расширения файла, его имя совпадает с именем папки (т.е. тоже gfx)
- существует в коммите №2

3. Совпадение имён папки и этого файла при чекауте между коммитами 1 и 2, несмотря на то что они существуют врозь в разных коммитах, приводит к исчезновению обоих.

Я удалял папку просто в проводнике, ничего об этом не говоря git'у.
Однако, делая второй коммит видел, что там статус - "папку - удалить, файл - добавить", т.е. git всё понял правильно.