Skip to content

Latest commit

 

History

History
361 lines (331 loc) · 28.7 KB

main.md

File metadata and controls

361 lines (331 loc) · 28.7 KB
Raw

Messages deleted from ru.stackoverflow.com

Q: Системы контроля версий - 24 мая '12 в 20:23, автор: Costantino Rupert

Всем привет!

  • Меня интересует мнение опытных пользователей систем контроля версий по поводу сражения Subversion vs Git, равно как и DVCS vs CVCS.

  • В первую очередь интересны практические user stories:

  • Почему был осуществлен переход с Subversion на Git и по какой причине (если так произошло) вернулись к использованию Subversion?
  • Насколько тяжелой на практике оказывается Git learning curve по сравнению с аналогичной для Subversion? Как прошла смена идеологии для сотрудников / членов команды?
  • Какие проблемы испытывались при интеграции того или иного решения для контроля версий в production workflow? Также очень хотелось бы послушать про налаживание взаимодействия с системами Continuous Integration на примерах TeamCity / Hudson / Jenkins / CruiseControl.
  • Какое впечатление осталось от поддержки той или иной VCS в современных IDE (с акцентом на Visual Studio 2005+)?
  • Остались ли негативные впечатления от реализации merge в той или иной системе контроля версий?
  • Насколько ощущается нехватка Git-specific features в Subversion, а именно git stash, git bisect, git rebase, git amend и идеологии локальных коммитов вообще?
  • Испытывались ли серьезные проблемы с CRLF / autocrlf в Git и каким образом эти проблемы решались?
  • Насколько появление аналога github / bitbucket для Subversion могло бы изменить ваше впечатление от использования данной системы контроля версий?
  • Если есть интересные соображения аналогичного характера на тему Mercurial / Bazaar / Veracity vs Subversion, то с радостью их выслушаю.

Постараюсь вознаградить качественные и интересные ответы соответствующим количеством своей репутации :)

A: https://ru.stackoverflow.com/a/113413/240512 - 25 мая '12 в 11:35, автор: Barmaley

Работаю в основном с Subversion (для тех кто в танке: он же SVN). Ушел в Subversion из CVS лет 5-6 назад. Основная причина была неспособность к адекватной настройке работы CVS при работе из-под firewall'а. По специфике своей деятельности мне постоянно приходится работать из-под довольно разношерстного набора файрволлов и никогда нет уверенности в том, что репо CVS будет доступен. После пары серьезных фиаско стоивших немало и денег и нервов - пересел под Subversion и доволен как слон.

Пару лет назад когда стал особенно моден Git - начал пробовать работать с ним. Осваивается после центр-ориентированного VCS очень тяжело. Идеология Git (опять же для тех кто в танке) - состоит в распределенном репо. То есть у каждого юзера есть своя локальное репо, которое хитрым образом синхронизируется. Кроме того еще одной особенностью Git является работа через свой порт (9418) - с которым ясное дело файрволлы не шибко дружат. Он хоть и поддерживает работу через 80-й порт (HTTP), но работает через него очень медленно. Ну и еще одним серьезным минусом Git считаю требования к каналу связи. Поскольку репо распределенное, то простой апдейт может вылиться в довольно длительное действо. А иногда бывает и работаешь через узенький канальчик GPRS - будет неприятно! С SVN таких проблем нет.

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

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

Сильно не копал, но у меня создалось ощущение что нормального Windows клиента для Git нет. Спору нет - под Lunux он работает замечательно, но под Виндой живет хреновастенько (в отличие от SVN).

Упдате

По поддержке VCS различными IDE. SVN отвратительно поддерживается под Eclipse. Есть, если память не изменяет 2 плагина, и оба работают плохо. Постоянно ругаются то на несовпадение версий плагинов, то отстутствие самого SVN. В общем требуют танцев с бубнами. Правда, после настройки работают нормально. Связка Netbeans-SVN работает хорошо - нареканий нет, равно как и связка IDEA-SVN. По Visual Studio могу только вспомнить опыт работы с CVS (проблем не помню) и с великим и ужасным Visual SourceSafe (также проблем не помню).

A: https://ru.stackoverflow.com/a/241105/240512 - 2 авг '13 в 13:42, автор: KoVadim

напишу и я свои ответы:)

Почему был осуществлен переход с Subversion на Git и по какой причине (если так произошло) вернулись к использованию Subversion?

В компании, где я работаю, старые проекты живут в cvs/svn. Новые - в основном в git. Проекты не переводили с одной системы контроля на другую.

Удивительно, но iOS программисты признают только cvs и ради него готовы мержить целый день. Андроид программисты легко перешли на git.

Насколько тяжелой на практике оказывается Git learning curve по сравнению с аналогичной для Subversion? Как прошла смена идеологии для сотрудников / членов команды?

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

Какое впечатление осталось от поддержки той или иной VCS в современных IDE (с акцентом на Visual Studio 2005+)?

На основании моих наблюдений, программисты, которые сразу начали пользоваться консолью очень быстро схватывают. А те, кто ищут gui в любом виде тупят, делают глупости. К примеру, один умудрился изуродовать свой локальный репозиторий, но потом, когда push'ил, оно не захотело (он там сильно накрутил, ручками в каталог .git лазил и правил файлы). Но оно не хотело и он нашел в настройках галочку, что бы делало force. Было ещё то приключение восстановить.

Остались ли негативные впечатления от реализации merge в той или иной системе контроля версий?

В целом, впечатления позитивные. Но пару раз была ситуация, когда после merge git поменял "автора строки". Потом приходилось доказывать, что ты такого написать не мог. Но хорошо хоть есть подробная история и такое дело было вычислено.

Была ещё одна ситуация, когда в результате мерджа в результирующем файле пропала строка. Как такое случилось - не понятно.

Насколько ощущается нехватка Git-specific features в Subversion, а именно git stash, git bisect, git rebase, git amend и идеологии локальных коммитов вообще?

git stash - трудно дается людям в освоении. Не знаю почему. А вот подтрунивать (то есть, троллить) программистов с cvs/svn - самое оно. Им похоже такого не хватает и они изголяются через копирование и дифы.

Локальные коммиты - это также очень хорошо. Иногда в офисе пропадает интернет. Работа некоторых отделов останавливается...

Испытывались ли серьезные проблемы с CRLF / autocrlf в Git и каким образом эти проблемы решались?

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

Насколько появление аналога github / bitbucket для Subversion могло бы изменить ваше впечатление от использования данной системы контроля версий?

А разве они не существуют? google code и SF.net.

===========

А так, дома, когда делаю свои маленькие проектики, то обычно сразу добавляю их в git. Как я делал бы подобное так быстро с cvs/svn - не представляю.

A: https://ru.stackoverflow.com/a/113398/240512 - 25 май '12 в 11:10, автор: Yura Ivanov

Не претендую на опытного пользователя, но имел дело с Bazaar.

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

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

Знакомство с bzr+svn начал со статьи у Ивана Сагалаева, дальше по настройке базара есть несколько очень полезных статей в "Базарном дне".

Тут как видно не пришлось делать выбор между распределенной и обычной cvs. Если бы он, этот выбор, стоял, выбрал бы распределенную, возможности и удобства несомненны. Хотя проще использования svn пока не видел, но если честно не искал )

A: https://ru.stackoverflow.com/a/268732/240512 - 4 ноя '13 в 9:44, автор: sys_dev

Добавлю и свой опыт. Использовал за свою практику разработки Perforce, Subversion, Mercurial. В данный момент юзаю SVN на работе, а Mercurial дома. Последний мне больше нравится, а про Perforce и вспоминать не хочу!

Что дает мне Mercurial?

  1. Поощряет эксперименты. Если вдруг у меня в голове возникла шальная мысль, то в случае, если нахожусь дома, то не парюсь и тут же пишу "hg branch idea-name". Если же на работе, то возникает мысль : "А вдруг моя идея полный бред?". Напомню, что на работе юзаю SVN. В случае SVN бранч остается "на всю жизнь" и его уже не удалить. В случае Mercurial все живет локально до момента "hg push". В процессе работы над возникшей идей можно понять, что она имеет ценность только спустя некоторое время. Можно запилить, показать шефу и если это имеет ценность для бизнеса, тогда и запушить, в противном случае после слов "Это нафиг никому не надо" достаточно легко сделать "rm -rf ./directory-with-sources".

Итоговая мысль: Mercurial не сковывает меня мыслью "А что если то что я запилю окажется ересью?", он предоставляет средство быстро убрать,но в тоже время и поделиться результатом, если то что запилил оказалось ценным!

  1. Большая секьюрность. Репозитарий не зависит от файлового расположения. Если вы сделали hg update в одну папку, а затем перенесли на другой диск, то это не означает, что что-то перестанет работать. Все будет будет работать как и прежде. Другими словами, репозитарий можно склонировать в TrueCrypt-контейнер и не париться, что при открытии шифрованного контейнера может поменяться буква диска. Если клонировали на h:\my-project , а в след. раз открыли как g:\my-project, то все будет работать как и прежде.

Итоговая мысль: Mercurial нужны только содержимое папок репозитарий, точнее папочка '.hg'. А где она сейчас расположена на d:\projects или на g:\work-projects\personal\ уже не важно, важно лишь наличие '.hg' и чтобы это был "тот самый .hg'. Из-за этой гибкости достаточно легко ложить проекты в шифрованные контейнеры.

Легко показать результат. И вправду легко, просто набиваешь 'hg serve'. Это запускает локальный веб-сервер и можно будет поделиться ссылкой, чтобы на "мой говнокод" взглянули. Мне не нужно для этого заливать исходники на центральный сервер или же архивировать и слать по почте.

Итоговая мысль: Чтобы показать коллеге то что я запилил, достаточно заюзать команду 'hg serve' и кинуть ссылку по скайпу\аське\джаббер.

A: https://ru.stackoverflow.com/a/241097/240512 - 2 авг '13 в 13:17, автор: Михаил М

С удовольствием работаю с Subversion (правда, обычно, в однопользовательском режиме). Соответственно не претендую на хоть какую-то полноту опыта.

Примерно год работал c GIT. Под Windows графических нормальных тулов не было, на Mac OS коммитил через графический тул, более сложные вещи делал из командной строки. Моё мнение про GIT: очень сложно и нелогично. Потому что надо знать очень много мелких вещей чтобы каждый раз из них собирать, как из конструктора то, что надо сделать. И похожие вещи делаются из командной строки по-разному. Да, работает быстро и репозиторий локально, но это не настолько полезно. С ветками тоже у нас народ старался не работать. Разбираться с GIT всем было тяжело (речь о программистах)

A: https://ru.stackoverflow.com/a/241782/240512 - 5 авг '13 в 10:23, автор: actionless

Мне сам распределенный подход гит'а кажется более логичным. "learning curve", я бы сказал, примерно такой же. так же рекомендую обратить внимание на mercurial (hg) -- он идеалогически очень близок к гит'у , есть поддержка этой системы у битбакета, и, вроде, в бета-режиме на гитхабе, но есть несомненное преимущество -- каждый коммит "знает" из какого бранча он появился в текущем, в отличии от гит'а

A: https://ru.stackoverflow.com/a/256604/240512 - 27 сен '13 в 11:08, автор: mals

У Subversion есть преимущество: в одном хранилище можно расположить все проекты. Идеология GIT требует каждый проект хранить в отдельно хранилище. Т.е. если вы пользуетесь платными услугами, как например JIRA, то за каждое ваше хранилище придётся платить отдельно. (наверное, поэтому они и закрыли услугу Subversion.)

Q: Я решила изучать компьютер, так как одинока ! Мой вопрос о JavaScript - 9 апр '18 в 19:28, автор: Bella Ellen Black

Посоветуйте, с каких книг начать, чтобы не быть придурком в плане понимания компьютера (две трети жизни знаю только то, что наглядно на кнопочках). ЭТО ДЛЯ НАЧАЛА. Я помню, что в школе умела решать задачи по информатике, но есть ли толк в школьных учебниках? Я собираюсь всегда быть одна и хочу знать компьютер так, чтобы принести пользу. Постольку поскольку есть на это время, но очень нужны грамотные указания.

НО ГЛАВНОЕ -хочу Изучать компьютер более профессионально, прежде всего программирование. Главная причина -мне нужно для жизни зарабатывать деньги, с людьми я общаться почти не могу, у меня нервное заболевание и я не люблю скрывать что-то о себе, и вообще людей не очень воспринимаю, меня окружают мещане и тупицы, а на черной работе работать здоровье не позволяет. Мне около 30, и я легко могу все осваивать новое, училась я всегда прекрасно, но не нашла себя в жизни. Но... я не математик если честно.

Помогите, кто чем может. также интересует дизайн и создание сайтов, программирование и смогу ли я все это освоить. Я настойчива, и добьюсь своего, я трудолюбива. Очень хочу изучать компьютер, но нужна моральная поддержка, и какой-то толчок и направление извне. Сама я не могу сориентироваться, я ничего не знаю, кроме самого тривиального

Q: Администрация сплошное быдло? - 8 авг '18 в 13:23, автор: Sergey Usick

В нашем офисе работает около 30 сотрудников, сегодня заблокировали аккаунт моего начальника под предлогом накрутки, ему глубоко насрать на ресурс с ущербной администрацией. И последнее, что осечка вышла ? вменяете использование нескольких аккаунтов ! заблокируйте всю сеть Триолан и медиасити-ком - так вышло что это наши сети . Мелочные, ущербные, врущие, модераторы говнокодеры. Пошли лесом!

Мы поступим сл. образом заблокируем доступ к вашему ресурсу с нашего региона, а это 52 миллиона ip адресов - и пользователей интернета. всего хорошего !

Q: Сложение чисел в JavaScript - 25 окт '19 в 13:25, автор: user356453

Нам по информатике дали задание. Подскажите, как правильно написать простую функцию сложения двух чисел a и b.

Я пытался так:

function = sum(a, b) { console(a + b) }

но ничего не заработало!

Вот такая ошибка: введите сюда описание изображения

Спасибо.

A: https://ru.stackoverflow.com/a/1038604/240512, автор: Александр Великий

Рабочее простое решение, функция amount:

const amount = (a, b) => {
const data = {
    fn: a,
    sn: b,
    g: 'getComPart',
    f: 'f',
    getComPart: {
        f: 'computed'
    },
    n: 'n',
    computed: (a) => {
        let z = data['s' + [data[data.n]]];

        while (z) {a++; z--;}
        return a;
    }
}

return data[data[data.g].f](data['f' + data.n]);
}

console.log(amount(3, 5)) // 8

Q: Как мотивировать программистов писать код? - 24 дек '19, автор: Turok

В общем, работаю менеджером в одной крупной кампании и мне кажется, что программисты не достаточно эффективно работают... Хохочат, кидаются мемчиками.

У меня были такие мысли:

  1. Сделать в клодовой карцер для программистов, где они должны провести целый день в темноте со светлой темой
  2. Купить хорошим программистам шаверму на вокзале, а самых плохих заставить драить унитазы потом.

Как вы считаете, поднимется ли эффективность?