svn — ъ, git — ъ, perforce — не ъ потому что платное. Зачем что-то коммерческое, когда есть svn (Redmine — замечательнейшая штука), git, или mercurial.
А github и sourceforge — самые популярные ресурсы такого рода.
может быть, чуточку и удобнее. потому что проще. но свою задачу, а именно управление ветками и версиями Перфорс выполняет гораздо лучше. Бывало ли что вдруг перестает билдиться проект потому что в нем появляются всякие строки типа >>>>mine >>>>theirs ??? из-за того что сделал апдейт, а он не смог смерджить сам… или эти вечные "please, make cleanup", который совсем не помогает… но у СВН есть замечательный плюс — он бесплатный.
DonKihot, а почему бы не вести версионный контроль для, скажем, документов перевозочных ? Или курсовиков/лаб у студентов? Что в этом узкоспециализированного ?
К началу 2013 года cygwin перестал быть единственной альтернативою, благо появился (msysgit.github.com/) msysgit (в двух вариантах, один из которых называется почему-то «Git for Windows»).
Любители делать всё в стиле Windows (то есть не из командной строки, а непременно при помощи меню и жмяков мышóю, что не предполагает заучивания команд наизусть и притом может делаться из положения лёжа с рукою на мышке не глядя на клавиатуру) могут в дополнение к msysgit поставить себе (code.google.com/p/tortoisegit/) TortoiseGit и тем невозбранно достигнуть желаемого. Я поставил.
Из трёх вышеперечисленных систем я советую именно Git, а вместо данного автором совета комментария «не обязательно разворачивать сервер у себя на машине — можно воспользоваться общедоступными» я даю вам комментарий совершенно противоположный: радуйтеся, что совершенно не обязательно выкладывать свой исходный код (или другой продукт, подвергаемый контролю версий) на общедоступный сервер в Интернете; более того, не обязательно даже вообще подключаться к Интернету. Вместо того Git (как и всякая другая система распределённого контроля версий — Mercurial, например) не только позволяет так работать, но и неизбежно работает именно таким образом, при котором у каждого разработчика имеется локальная копия всего кода и всего учёта версий, необходимого ему для работы.
Именно этим обеспечивается необыкновенно быстрое выполнение всех тех операций, для которых добрые люди обыкновенно заводят у себя систему контроля версий. И оформление новой версии (так называемый commit), и разветвление (branching), и слияние ветвей (merge), и откат к любой предыдущей версии (в случае обнаружения ошибок) происходит практически мгновенно, потому что DVCS (distribured version control system, распределённая система контроля версий) в таком случае общается только с жёстким диском на компьютере оператора, а не лезет в Интернет.
Интернет (и некоторый центральный сервер на нём) используется только для обмена кодом между разработчиками, для слияния их индивидуальных разработок. И даже когда при слиянии возникают конфликты, то их устранение достигается забиранием кода с центрального сервера на свой компьютер, слиянием его у себя (с постепенною зачисткою конфликтующих элементов) и отсылкою обратно на сервер.
Дополнительно скажу ещё, что система контроля версий даёт разработчику не только чувство уверенности в безошибочности своего труда (предоставляет возможность отката к какой угодно более ранней версии в случае возникновения какой угодно ошибок), хотя именно это свойство является основным побуждением к заведению у себя такой системы.
Помимо этого система обеспечивает возможность самоорганизации труда. Список версий (log) является зримым воплощением каждой вехи свершений разработчика, обеспечивает его возможностью наблюдать темпы своего труда по мере хода времени, а подчас и побуждает стыдиться потерянным дням, напрасно истраченным на менее важные дела (скажем, на чтение советов и комментариев на Кстатиде).
Попробуйте (fossil-scm.org/fossil/doc/trunk/www/index.wiki) fossil, после SVN, Git и Mercurial пользуюсь и ничего другого не хочется. Во-первых прекрасный интерфейс в браузере, (fossil-scm.org/fossil/timeline) таймлайны а-ля GitHub, которые позволяют отслеживать изменения очень наглядно даже локально, во-вторых это один кросплатформенный бинарник и весь репозиторий тоже храниться в одном файле, в третьих — возможность элементарно поднять свой сервер (одной командой) с репозиторием, плюс встроенный (fossil-scm.org/fossil/rptview?rn=1) багтрекер, встроенная система (fossil-scm.org/fossil/doc/trunk/www/permutedindex.wiki) документации с Wiki разметкой, которые разворачиваются вместе с сервером, в четвертых предельно лаконичный хелп на каждую команду ((fossil-scm.org/fossil/help/init) например) В пятых всё это собранно на SQLite командой разработавшей SQLite, что является отличной гарантией надежности, в шестых не просто бесплатно, а даже OpenSource.
Есть один большой недостаток — это не GIT и поэтому даже несмотря на очень низкий порог вхождения часть разработчиков всё же отсеется, плюс комьюнити гораздо меньше чем на GitHub'е, но для своих внутренних проектов или узкоспециальных Fossil — ИМХО идеален.
Все ссылки ведут на репозиторий самого фоссиля, под фоссилем. Любой новый проект выглядит именно так (после наполнения контентом) причем так он выглядит локально, без всякой нужды в GitHub, BitBucket и пр. но может быть легко развернут и в интернет.
И не ограничивайте применение систем контроля версий только кодом. Под ними хорошо хранить документы, даже бинарники (позволяет понять какие из десяти модулей задело изменение типа вон той глобальной переменной)
Я вот сэйвы для игр которые позволяют только один сейв (при выходе) типа FLT или DwarfFortress храню под fossil, поскольку удобно и гораздо меньше места занимает, да разные применения есть, не ограничивайте себя.
1 IT
1 компьютеры
1 программирование
svn — ъ,
git — ъ,
perforce — не ъ потому что платное. Зачем что-то коммерческое, когда есть svn (Redmine — замечательнейшая штука), git, или mercurial.
А github и sourceforge — самые популярные ресурсы такого рода.
Perforce можно пользовать бесплатно до 2х пользователей.
удобнее я ничего не пользовал
svn и tortoise svn во много раз удобнее.
может быть, чуточку и удобнее. потому что проще. но свою задачу, а именно управление ветками и версиями Перфорс выполняет гораздо лучше.
Бывало ли что вдруг перестает билдиться проект потому что в нем появляются всякие строки типа
>>>>mine
>>>>theirs
???
из-за того что сделал апдейт, а он не смог смерджить сам…
или эти вечные "please, make cleanup", который совсем не помогает…
но у СВН есть замечательный плюс — он бесплатный.
вобщем, на вкус и цвет фломастеры разные…
=)
для заинтересовавшихся, но незнакомых…
Система управления версиями
1 очень специализированный совет
DonKihot, Вот только заметил. А чем отличается этот тег от Гурьевска?
mao_dzen, ну, во-первых, он родился раньше "Гурьевска", а во-вторых, более понятен для тех, кто не знаком с "Гурьевском" точнее отражая ситуацию.
DonKihot, Спасибо. Но может его слить так как под ним только три совета а под гурьевком около 50
mao_dzen, ничего не буду иметь против. Делайте, как посчитаете нужным, раз Вы считаете, что более понятный тег лучше менее понятного.
mao_dzen, ну… в смысле наоборот :)
mao_dzen, я считаю, что Гурьевск должен ставиться интересным и необычным советам, а этот всем остальным узкоспециализированным.
DonKihot, а почему бы не вести версионный контроль для, скажем, документов перевозочных ? Или курсовиков/лаб у студентов? Что в этом узкоспециализированного ?
git можно использовать и локально, без сервера. Под Windows его тоже можно использовать, под Cygwin.
К началу 2013 года cygwin перестал быть единственной альтернативою, благо появился (msysgit.github.com/) msysgit (в двух вариантах, один из которых называется почему-то «Git for Windows»).
Любители делать всё в стиле Windows (то есть не из командной строки, а непременно при помощи меню и жмяков мышóю, что не предполагает заучивания команд наизусть и притом может делаться из положения лёжа с рукою на мышке не глядя на клавиатуру) могут в дополнение к msysgit поставить себе (code.google.com/p/tortoisegit/) TortoiseGit и тем невозбранно достигнуть желаемого. Я поставил.
Mithgol, еще приятная штука (www.atlassian.com/software/sourcetree/overview) Atlassian SourceTree
Из трёх вышеперечисленных систем я советую именно Git, а вместо данного автором совета комментария «не обязательно разворачивать сервер у себя на машине — можно воспользоваться общедоступными» я даю вам комментарий совершенно противоположный: радуйтеся, что совершенно не обязательно выкладывать свой исходный код (или другой продукт, подвергаемый контролю версий) на общедоступный сервер в Интернете; более того, не обязательно даже вообще подключаться к Интернету. Вместо того Git (как и всякая другая система распределённого контроля версий — Mercurial, например) не только позволяет так работать, но и неизбежно работает именно таким образом, при котором у каждого разработчика имеется локальная копия всего кода и всего учёта версий, необходимого ему для работы.
Именно этим обеспечивается необыкновенно быстрое выполнение всех тех операций, для которых добрые люди обыкновенно заводят у себя систему контроля версий. И оформление новой версии (так называемый commit), и разветвление (branching), и слияние ветвей (merge), и откат к любой предыдущей версии (в случае обнаружения ошибок) происходит практически мгновенно, потому что DVCS (distribured version control system, распределённая система контроля версий) в таком случае общается только с жёстким диском на компьютере оператора, а не лезет в Интернет.
Интернет (и некоторый центральный сервер на нём) используется только для обмена кодом между разработчиками, для слияния их индивидуальных разработок. И даже когда при слиянии возникают конфликты, то их устранение достигается забиранием кода с центрального сервера на свой компьютер, слиянием его у себя (с постепенною зачисткою конфликтующих элементов) и отсылкою обратно на сервер.
Дополнительно скажу ещё, что система контроля версий даёт разработчику не только чувство уверенности в безошибочности своего труда (предоставляет возможность отката к какой угодно более ранней версии в случае возникновения какой угодно ошибок), хотя именно это свойство является основным побуждением к заведению у себя такой системы.
Помимо этого система обеспечивает возможность самоорганизации труда. Список версий (log) является зримым воплощением каждой вехи свершений разработчика, обеспечивает его возможностью наблюдать темпы своего труда по мере хода времени, а подчас и побуждает стыдиться потерянным дням, напрасно истраченным на менее важные дела (скажем, на чтение советов и комментариев на Кстатиде).
1 как попасть из Калининграда в Гурьевск
Этот совет всегда заставляет меня нервно вздрогнуть.
Отчего именно такая реакция?
Mithgol, формулировка такая, по смыслу совета ничего не имею против, я все равно не понимаю, о чем там речь =)
Попробуйте (fossil-scm.org/fossil/doc/trunk/www/index.wiki) fossil, после SVN, Git и Mercurial пользуюсь и ничего другого не хочется. Во-первых прекрасный интерфейс в браузере, (fossil-scm.org/fossil/timeline) таймлайны а-ля GitHub, которые позволяют отслеживать изменения очень наглядно даже локально, во-вторых это один кросплатформенный бинарник и весь репозиторий тоже храниться в одном файле, в третьих — возможность элементарно поднять свой сервер (одной командой) с репозиторием, плюс встроенный (fossil-scm.org/fossil/rptview?rn=1) багтрекер, встроенная система (fossil-scm.org/fossil/doc/trunk/www/permutedindex.wiki) документации с Wiki разметкой, которые разворачиваются вместе с сервером, в четвертых предельно лаконичный хелп на каждую команду ((fossil-scm.org/fossil/help/init) например) В пятых всё это собранно на SQLite командой разработавшей SQLite, что является отличной гарантией надежности, в шестых не просто бесплатно, а даже OpenSource.
Есть один большой недостаток — это не GIT и поэтому даже несмотря на очень низкий порог вхождения часть разработчиков всё же отсеется, плюс комьюнити гораздо меньше чем на GitHub'е, но для своих внутренних проектов или узкоспециальных Fossil — ИМХО идеален.
Все ссылки ведут на репозиторий самого фоссиля, под фоссилем. Любой новый проект выглядит именно так (после наполнения контентом) причем так он выглядит локально, без всякой нужды в GitHub, BitBucket и пр. но может быть легко развернут и в интернет.
И не ограничивайте применение систем контроля версий только кодом. Под ними хорошо хранить документы, даже бинарники (позволяет понять какие из десяти модулей задело изменение типа вон той глобальной переменной)
Я вот сэйвы для игр которые позволяют только один сейв (при выходе) типа FLT или DwarfFortress храню под fossil, поскольку удобно и гораздо меньше места занимает, да разные применения есть, не ограничивайте себя.