Comments 60
мне кажется, эта тема уже неоднократно освещалась в различных топиках:
упс… запостил случаем.
поиск:
habrahabr.ru/search/? q=svn+trac
вот неплохая версия:
habrahabr.ru/blogs/development/29440/
давеча даже распечатал с хабра одну из подобных статей. к сожалению, уже не помню, какую.
думаю, интереснее было бы почитать про svn+trac, т.к. svn поднимается достаточно просто… (например skazkin.habrahabr.ru/blog/29716/).
а еще есть интересные плаги:
для Visual Studio: VSTrac (для трака), и ankhsvn для SVN.
для Eclipse: Mylyn (для трака и JIRA), SVNKit для SVN собсно.
может, как add-in к статье)
поиск:
habrahabr.ru/search/? q=svn+trac
вот неплохая версия:
habrahabr.ru/blogs/development/29440/
давеча даже распечатал с хабра одну из подобных статей. к сожалению, уже не помню, какую.
думаю, интереснее было бы почитать про svn+trac, т.к. svn поднимается достаточно просто… (например skazkin.habrahabr.ru/blog/29716/).
а еще есть интересные плаги:
для Visual Studio: VSTrac (для трака), и ankhsvn для SVN.
для Eclipse: Mylyn (для трака и JIRA), SVNKit для SVN собсно.
может, как add-in к статье)
Рекомендую обратить внимание на Git. Пост про установку SVN попахивает детством. Вы бы еще про CVS написали…
никак не могу понять, чем Git «взрослее» нежели subversion, или CVS… мне кажется, просто в различных разработках применяются тулзы, которые удобнее для данной разработки…
Во-первых Git правильно организован, в отличие от того же svn. Во-вторых более широкие возможности работы с репозиторием. Ну и как вариант — при использовании гита автору для одного себя не понадобилось бы поднимать сервер, так как гит и без сервера отлично работает.
Насчет «в различных разработках применяются тулзы, которые удобнее для данной разработки», все перечисленные инструменты служат одной цели — версионный контроль. И удобство можно лишь оценивать по большим или меньшим возможностям работы с версиями. Вот тут гит все мейнстримныe vcs и опережает на голову.
Насчет «в различных разработках применяются тулзы, которые удобнее для данной разработки», все перечисленные инструменты служат одной цели — версионный контроль. И удобство можно лишь оценивать по большим или меньшим возможностям работы с версиями. Вот тут гит все мейнстримныe vcs и опережает на голову.
разработка ведётся не на машине с репозиторием, так что сервер поднимать бы всё-таки пришлось.
* ушёл читать добро от тов. los_t.
* ушёл читать добро от тов. los_t.
Кстати да, заметки от los-t помогают понять какой гит внутри. Ну и рекомендую peepcode.com/products/git-internals-pdf и peepcode.com/products/git
при использовании гита автору для одного себя не понадобилось бы поднимать сервер, так как гит и без сервера отлично работает.
SVN тоже умеет
для использования SVN для одного не требуется поднимать сервер также… ставите tortoisesvn и локальный репозиторий вполне нормально работает.
я пишу на c# в данный момент. использую VS. для работы использую плаг для VS->SVN. когда работаю под Eclipse, использую плаг для Eclipse. вот вам и удобства в разработке. если кому нравится работать отдельным интерфейсом — пусть юзает Git. я достаточно долго выбирал оптимальный для себя вариант. SVN оказался найудобнейшим.
кроме всего, «более широкие возможности» — очень сильно звучит. опишите поподробнее, т.к. аргументации я по-прежнему не увидел. и «опережения на голову» также не вижу… под винду смотрел git. я не впечатлен, по правде. сейчас посмотрю еще раз, дабы не быть субъективным…
я пишу на c# в данный момент. использую VS. для работы использую плаг для VS->SVN. когда работаю под Eclipse, использую плаг для Eclipse. вот вам и удобства в разработке. если кому нравится работать отдельным интерфейсом — пусть юзает Git. я достаточно долго выбирал оптимальный для себя вариант. SVN оказался найудобнейшим.
кроме всего, «более широкие возможности» — очень сильно звучит. опишите поподробнее, т.к. аргументации я по-прежнему не увидел. и «опережения на голову» также не вижу… под винду смотрел git. я не впечатлен, по правде. сейчас посмотрю еще раз, дабы не быть субъективным…
Начните с blog.tarantsov.com/2007/12/nine-reasons-to-use-git.html и просмотрите www.youtube.com/watch? v=4XpnKHJAok8 Дальше только детальное изучение.
Не стоит забывать что все большее количество разработчиков (особенно под web) мигрируют с windows на альтернативные OS. Я работаю на Leopard+Textmate и пользуюсь консольным интерфейсом git. В свое время активно пользовался и VS и Eclipse поэтому знаю о чем говорю — консольный интерфейс при грамотном использовании не менее эффективен чем виндовые поделки.
Не стоит забывать что все большее количество разработчиков (особенно под web) мигрируют с windows на альтернативные OS. Я работаю на Leopard+Textmate и пользуюсь консольным интерфейсом git. В свое время активно пользовался и VS и Eclipse поэтому знаю о чем говорю — консольный интерфейс при грамотном использовании не менее эффективен чем виндовые поделки.
Да, git вообще клёвая штука. Я пытался вначале разобраться с bzr, не мог вкурить по-нормальному. Взглянул на гит, легко нашел документацию. Всё хорошо описано, да и сам гит построен очень даже логично и рационально, поэтому осилить его — не проблема. А умеет он всё то же, что и svn, плюс разные полезные плюшки в нагрузку.
1. Пост про svn, а не svn и другие системы
2. Напоминает старый анекдот:
Приходит покупатель в магазин:
(покупатель)-У вас туалетная бумага есть?
(продавец)-Туалетной нет, есть наждачная, брать будете?
2. Напоминает старый анекдот:
Приходит покупатель в магазин:
(покупатель)-У вас туалетная бумага есть?
(продавец)-Туалетной нет, есть наждачная, брать будете?
Тема не раскрыта — про «автоматическое обновление проекта» ни слова не сказано.
Настроим обновление рабочей копии при коммите — хук /usr/share/svn/hooks/post-commit
а это?..
А зачем что-то вырезать?
Почему нельзя сразу сделать svn up в рабочей версии на сервере?
Или вы таким образом пытаетесь сделать оптимизацию — дескать если изменения не затронули trunk, то и не выкладывать?
И еще момет — по какому урлу рабочая версия лезет в репозитарий?
Есть подозрение, что процесс встанет на запросе пароля к репозитарию.
Почему нельзя сразу сделать svn up в рабочей версии на сервере?
Или вы таким образом пытаетесь сделать оптимизацию — дескать если изменения не затронули trunk, то и не выкладывать?
И еще момет — по какому урлу рабочая версия лезет в репозитарий?
Есть подозрение, что процесс встанет на запросе пароля к репозитарию.
subversion.tigris.org/faq.html#website-auto-update
приведённый мной скрипт:
* может работать с более чем одним проектом
* блокирует\пытается обновить только те каталоги, в которые были внесены изменения (т.о. время коммита уменьшается)
* не требует перекомпиляции после внесения в него изменений :)
* может работать с более чем одним проектом
* блокирует\пытается обновить только те каталоги, в которые были внесены изменения (т.о. время коммита уменьшается)
* не требует перекомпиляции после внесения в него изменений :)
Второй пункт сомнительный.
Апдейт с локального сервера 350 мегабайт бинарных данных (из них изменено около 150) занимает около 1.5—2.5 секунд. У Вас столько исходников есть? (на текстовые данные делается diff и передается уже он).
Апдейт с локального сервера 350 мегабайт бинарных данных (из них изменено около 150) занимает около 1.5—2.5 секунд. У Вас столько исходников есть? (на текстовые данные делается diff и передается уже он).
UFO just landed and posted this here
от чёрт… я Вам ниже ответил :)
Чтобы сделать раздельные коммит и пуш, не обязательно разбираться с гитом, когда уже есть svn. Можно просто разобраться с rsync и делать пуш им.
Во-вторых, практика автоапдейта проекта после коммита порочна.
Чем порочна? Само собой не надо выкладывать на рабочий сервер, а только на тестовый — думаю в этом плане как раз удобно. Закоммитил, протестировал проект целиком.
практика автоапдейта проекта после коммита порочна.В курсе. Основная часть разработки идёт у меня на машине — там же и тестится на апаче. Коммит делается только после пройденных тестов.
Часто бывает такое, что стоит закоммитить нерабочий код.На этот случай ведь можно распилить репозиторий на 2 части: собственно для закидывания коммитов и для отлаженных участков… У меня подобных проблем пока не возникало — над проектом один работаю, так что не задумывался над этой проблемой.
советую сразу разбираться с гитомДома на досуге обязательно поковыряю… кхе… осталось дождаться досуга :)
спасибо.
Мне кажется поднимать svnd — очень нерационально для такой простой задачи.
Для этого хватит svn+ssh:// который работает куда приятнее. + есть возможность использовать ключ -c, который включает компрессию на ssh-тунель.
Для этого хватит svn+ssh:// который работает куда приятнее. + есть возможность использовать ключ -c, который включает компрессию на ssh-тунель.
а для какой задачи поднятие svnd было бы рационально?
В тех случаях, когда над проектом работает больше 2-3 человек рационально поднимать svnd или webdav (http[s]).
Один-два человека прекрасно могут работать с svn'ом через ssh и не нагружать сервер лишним демоном (светить открытый порт).
NB. Напишите, пожалуйста, про права доступа к репозитарию. Этот момент в статье не освещен и многие могут просто не подумать об этом. Результатом будет куча репозитариев с анонимным чекаутом.
Один-два человека прекрасно могут работать с svn'ом через ssh и не нагружать сервер лишним демоном (светить открытый порт).
NB. Напишите, пожалуйста, про права доступа к репозитарию. Этот момент в статье не освещен и многие могут просто не подумать об этом. Результатом будет куча репозитариев с анонимным чекаутом.
вопрос не совсем по теме…
Использую SVN (+tortoiseSVN) и очень доволен. Но не везде есть доступ к шеллу и установлен SVN.
Возможно кто-то в курсе тулзы, которая бы делала то же самое что и SVN, только с помощью залитых на сервер ПХП скриптов или(и) FTP протокола.
Использую SVN (+tortoiseSVN) и очень доволен. Но не везде есть доступ к шеллу и установлен SVN.
Возможно кто-то в курсе тулзы, которая бы делала то же самое что и SVN, только с помощью залитых на сервер ПХП скриптов или(и) FTP протокола.
Git наше все. Это раз. А два — для маленьких и средних проектов (с 1-5 разработчиками), нам все же удобнее пользовать фтп/сфтп и Coda как IDE/редактор
UFO just landed and posted this here
Оффтоп. Праздный интерес — побовали ли Вы текстмейт? Если да, то как можно попробовав текстмейт редактировать код в Coda?
На работе, в корпоративных задачах и условиях SVN есть Super Good!!!
Но для домашних/одиночных разработок я в конце концов счёл его несколько избыточным и остановился на Norton GoBack и т.п. утилитах, делающих журналирование всех изменений файловой системы с возможностью отката/восстановления отдельных файлов.
Но для домашних/одиночных разработок я в конце концов счёл его несколько избыточным и остановился на Norton GoBack и т.п. утилитах, делающих журналирование всех изменений файловой системы с возможностью отката/восстановления отдельных файлов.
Круто, а слияние branch'ей тебе тоже GoBack делает?
Я что хотел сказать, в том же SVN есть куча вещей, удобных даже для одиночной разработки, как то: ветви, комментирование коммитов (в goback можно откатиться к дате, но хрен вспомнишь что ты изменил и когда) и т.д.
И мне лично не понятно, что там такого «тяжёлого», что вместо использования специального софта извращаются с FTP, системами бекапа файлов и т.д. Для создания локального репозитория вообще же не надо устанавливать никакой сервер и т.д., средствами того же TortoiseSVN делается в пару кликов.
И мне лично не понятно, что там такого «тяжёлого», что вместо использования специального софта извращаются с FTP, системами бекапа файлов и т.д. Для создания локального репозитория вообще же не надо устанавливать никакой сервер и т.д., средствами того же TortoiseSVN делается в пару кликов.
BTW, что-то мне кажется что большинство товарищей агитирующих тут за svn разрабатывают на php. Верно?
Sign up to leave a comment.
Поднимаем subversion для приятной разработки