Что нынче круче SVN ?
Mercurial?
тьху стыд
hg, git, bzr и пр.
hg, git, bzr и пр.
а из перечисленных для ведения проекта "сайт на php + дизайн в темплейтах + набор служебных скриптов" какой лучше подходит?
С условием того, что локально можно поработать и в генту, но вот удаленно - только из под винды XP и 7 ?
С условием того, что локально можно поработать и в генту, но вот удаленно - только из под винды XP и 7 ?
Mercurial, т.е. hg
bzr
bzr
hgа из них что предпочесть ?
bzr
hg.
Но лично я предпочитаю git из фанатизма к языку реализации. Реальных преимуществ у него нету.
Но лично я предпочитаю git из фанатизма к языку реализации. Реальных преимуществ у него нету.
Если работаешь в одиночку, то Hg тебе не сильно поможет, он крут своей способностью мержить разные версии кода. Тебе и SVN хватит. А если разработчиков штук 10-15, то тогда Hg значительно круче SVN - меньше ручной работы по разрешению конфликтов, проще коммититься (перед этим не обязательно делать update, как в SVN).
А для гита под винду есть TortoiseGit, которые удобнее TortoiseHg.
а зачем? мне вот кажется, что эклипсовых плагинов и для hg и для git достаточно.
Черепашки — это более общие инструменты, чем интеграция с ide. Хотя последнее, конечно, предпочтительней.
Если работаешь в одиночку, то Hg тебе не сильно поможет, он крут своей способностью мержить разные версии кода. Тебе и SVN хватит. А если разработчиков штук 10-15, то тогда Hg значительно круче SVN - меньше ручной работы по разрешению конфликтов, проще коммититься (перед этим не обязательно делать update, как в SVN).херня
знаешь почему?
потому что настроить репозиторий git/hg – халява. А svn – не халява.
А svn – не халява.Почему не халява? Под винду есть visualsvn, там вообще никаких конфигов писать не надо. Без него — пару команд написать.
Потому что используется не только для исходников.
svnadmin create myrepo
Офигеть, как сложно настроить.
что-то там ещё было, не надо, я помню
Ну как же, необходимость придумывать отдельную директорию для репы, а потом чекаутить из нее. Феерические траблы с правами доступа, если комитить могут несколько локальных юзеров.
Тебе не рассказали про группы пользователей?
И, да, я смолчу про управление правами доступа в гите — про возможность ограничения коммитов только определенной папкой проекта, например. И про доступ к гиту по сети заодно смолчу, почему-то аналога удобному dav-svn всё нет и нет.
Про hg и bzr правда ничего не могу сказать, не пользовался, может там всё это есть.
И, да, я смолчу про управление правами доступа в гите — про возможность ограничения коммитов только определенной папкой проекта, например. И про доступ к гиту по сети заодно смолчу, почему-то аналога удобному dav-svn всё нет и нет.
Про hg и bzr правда ничего не могу сказать, не пользовался, может там всё это есть.
Тебе не рассказали про группы пользователей?
Слышал краем уха.
It can be quite tricky to get a bunch of users with existing SSH accounts to share a repository without permissions problems.
The SVN book подтверждает.
> что-то ещё надо было
Стоило поднять apache с mod_dav_svn (или как его там это позволит избежать проблем с правами. Я, во всяком случае к svn в локальной папке никогда не обращался.
Стоило поднять apache с mod_dav_svn (или как его там это позволит избежать проблем с правами. Я, во всяком случае к svn в локальной папке никогда не обращался.
папкещас тебя зачмырят!
И всё-таки, для персонального использования удобнее hg, чем svn по двум причинам: hg создаёт только одну директорию .hg в корне репозитория (не нужно настраивать исключения при поиске в файловом менеджере) и с hg-репозиторием можно работать как с папкой-проектом (например, записать на флешку).
(хотя, для пользователей студии есть одно небольшое преимущество последнего - AnkhSvn поудобнее чем VisualHG, но для людей, привыкших к командам scm, это не проблема, всё равно с файлами, не включёнными в проект VS, придётся не через плагин работать)
(хотя, для пользователей студии есть одно небольшое преимущество последнего - AnkhSvn поудобнее чем VisualHG, но для людей, привыкших к командам scm, это не проблема, всё равно с файлами, не включёнными в проект VS, придётся не через плагин работать)
Самое главное: а правда ли это, что если я перейду с svn на hg или даже git, то мой php-код станет лучше? И ещё, сейчас мой код лежит в cvs, наверное он совсем говно?
переходи на git. заодно и самооценку скорректируешь
> с hg-репозиторием можно работать как с папкой-проектом (например, записать на флешку).
Просто потрясающий своей красотой аргумент.
Ни разу не пробовал переписывать репозитории CVS/Subversion?
---
Расширь своё сознание!
Просто потрясающий своей красотой аргумент.
Ни разу не пробовал переписывать репозитории CVS/Subversion?
---
Расширь своё сознание!
>> папке
> щас тебя зачмырят!
А что такое файл?
---
...Я работаю антинаучным аферистом...
> щас тебя зачмырят!
А что такое файл?
---
...Я работаю антинаучным аферистом...
а мне вот непонятно, какие могут быть проблемы.
единственное место возникновения проблем - это использовать file:// в качестве доступа к репозиторию - но это же верх идиотизма! такое себе можно позволить только в однопользовательском режиме.
единственное место возникновения проблем - это использовать file:// в качестве доступа к репозиторию - но это же верх идиотизма! такое себе можно позволить только в однопользовательском режиме.
The SVN book подтверждает.Практический опыт у нас на работе подтверждает обратное. Легким движением руки добавляем пользователя в группу developers и брюки превращаются...
Кстати, еще из ряда "свн говно" расскажи мне, как в гите зачекаутить отдельную папку/файл проекта, обновить/откатить только один файл проекта до нужной ревизии, поправить в этой зачекаутенной папке что-нибудь и закоммитить обратно в origin-репу.
переходи на git. заодно и самооценку скорректируешьСпасибо за совет. Я так и думал!
>> папкеответ "напильник" подойдет, или ты по делу говоришь?
> щас тебя зачмырят!
А что такое файл?
> с hg-репозиторием можно работать как с папкой-проектом (например, записать на флешку).в случае svn телодвижений заметно больше.
Просто потрясающий своей красотой аргумент.
Ни разу не пробовал переписывать репозитории CVS/Subversion?
Кстати, еще из ряда "свн говно" расскажи мне, как в гите зачекаутить отдельную папку/файл проекта, обновить/откатить только один файл проекта до нужной ревизии, поправить в этой зачекаутенной папке что-нибудь и закоммитить обратно в origin-репу.ты уверен, что должен хотеть делать так?
Кстати, еще из ряда "свн говно" расскажи мне, как в гитеФормально этот вопрос конечно относится к разряду "как в гите сделать ровно то же что делает свн", но если тебе действительно интересен процесс, то вот как практически аналогичные действия делаются
зачекаутить отдельную папку/файл проекта,git clone для локальных реп практически бесплатен, либо делаешь ветку и в ней колупаешься, так что первый пункт опускаю (если чо, да, git не умеет делать клона поддиректорий репы)
обновить/откатить только один файл проекта до нужной ревизии,
поправить в этой зачекаутенной папке что-нибудь и
закоммитить обратно в origin-репу.
git reset REV PATH откатит файл до нужной версии
git commit PATH его закоммитит
git push origin зальёт эти изменения
Разве нет?
git clone для локальных реп практически бесплатен, либо делаешь ветку и в ней колупаешься, так что первый пункт опускаю (если чо, да, git не умеет делать клона поддиректорий репы)Всё здорово, но имело бы смысл только при выполнении первого пункта. Я не хочу клонировать сотню мегабайт удаленного проекта со всей историей ревизий, только чтобы поправить файл файл переводов.
git reset REV PATH откатит файл до нужной версии
git commit PATH его закоммитит
git push origin зальёт эти изменения
Разве нет?
ты уверен, что должен хотеть делать так?Да, уверен. Типичный пример, у проекта может быть набор переводов:
/translations/ru/
/translations/en/
/translations/es/
...
Во-первых, логично, когда переводчик может коммитить только в папку своего языка. Во-вторых, логично, что ему нафиг не нужно чекаутить всё остальное. Нет, говорит нам гит, ты, сука, выкачаешь всё, ты работаешь с Проектом, а не с файлами.
Всё здорово, но имело бы смысл только при выполнении первого пункта. Я не хочу клонировать сотню мегабайт удаленного проекта со всей историей ревизий, только чтобы поправить файл файл переводов.Ну сделай shallow clone и засабмить патч обратно, делов то. Никакую историю не надо вытягивать.
Ну сделай shallow clone и засабмить патч обратно, делов то. Никакую историю не надо вытягивать.shallow clone всё равно вытаскивает весь проект целиком. Несмотря на всю пианиста, over 9000 проектов до сих пор хранят в VCS бинарники и просто имеют большой вес.
>>> с hg-репозиторием можно работать как с папкой-проектом (например, записать на флешку).
>> Просто потрясающий своей красотой аргумент.
>> Ни разу не пробовал переписывать репозитории CVS/Subversion?
> в случае svn телодвижений заметно больше.
Покажите мне разницу.
---
"Vyroba umelych lidi, slecno, je tovarni tajemstvi."
>> Просто потрясающий своей красотой аргумент.
>> Ни разу не пробовал переписывать репозитории CVS/Subversion?
> в случае svn телодвижений заметно больше.
cp -R /path/to/svnroot /mnt/
cp -R /path/to/cvsroot /mnt/
Покажите мне разницу.
---
"Vyroba umelych lidi, slecno, je tovarni tajemstvi."
>>>> папке
>>> щас тебя зачмырят!
>> А что такое файл?
> ответ "напильник" подойдет, или ты по делу говоришь?
По делу.
В целом, это правильный перевод, он сохраняет, при очевидных условиях,
целостность отображения понятий в предметы окружающего мира.
Перевод "каталог" можно считать устаревшим, поскольку новые поколения
могут и не увидеть каталога в его современном (_уже_ --- не очень современном)
понимании.
Называть это "директорией" лично я по ряду причин считаю вредным.
---
...Я работаю антинаучным аферистом...
>>> щас тебя зачмырят!
>> А что такое файл?
> ответ "напильник" подойдет, или ты по делу говоришь?
По делу.
В целом, это правильный перевод, он сохраняет, при очевидных условиях,
целостность отображения понятий в предметы окружающего мира.
Перевод "каталог" можно считать устаревшим, поскольку новые поколения
могут и не увидеть каталога в его современном (_уже_ --- не очень современном)
понимании.
Называть это "директорией" лично я по ряду причин считаю вредным.
---
...Я работаю антинаучным аферистом...
Покажите мне разницу.вместо абстрактного /path/to/___root, который надо ещё помнить - вполне конкретный ~/myproject. Конечно, можно хранить всё рядом, но т.к. перемещение репозитория вызовет необходимость делать некие действия с рабочей копией, я бы предложил положить его подальше от домашней директории.
И, кстати, svn даже с локальным репозиторием работает заметно медленнее hg.
> вместо абстрактного /path/to/___root, который надо ещё помнить
Зачем его помнить, если это ~/cvsroot?
> перемещение репозитория вызовет необходимость делать некие действия с рабочей копией,
Я когда-то давно написал этот скрипт в одну строчку и больше не парюсь.
> я бы предложил положить его подальше от домашней директории.
"Его" это репозиторий? У меня лежит прямо тут,
никаких комплексов по этому поводу я не испытываю.
И, кстати, если ты боишься класть репозиторий близко,
то почему ты не боишься использовать всякое hg, где репозиторий
совмещён с рабочей копией?
---
...Я работаю антинаучным аферистом...
Зачем его помнить, если это ~/cvsroot?
> перемещение репозитория вызовет необходимость делать некие действия с рабочей копией,
Я когда-то давно написал этот скрипт в одну строчку и больше не парюсь.
> я бы предложил положить его подальше от домашней директории.
"Его" это репозиторий? У меня лежит прямо тут,
никаких комплексов по этому поводу я не испытываю.
И, кстати, если ты боишься класть репозиторий близко,
то почему ты не боишься использовать всякое hg, где репозиторий
совмещён с рабочей копией?
---
...Я работаю антинаучным аферистом...
И, кстати, если ты боишься класть репозиторий близко,С hg я могу наклонировать репозиториев столько, сколько захочу... Точнее, они могут ещё в качестве веток использоваться.
то почему ты не боишься использовать всякое hg, где репозиторий
совмещён с рабочей копией?
> С hg я могу наклонировать репозиториев столько, сколько захочу...
> Точнее, они могут ещё в качестве веток использоваться.
Ну а я умею клонировать репозитории CVS.
---
"Vyroba umelych lidi, slecno, je tovarni tajemstvi."
> Точнее, они могут ещё в качестве веток использоваться.
Ну а я умею клонировать репозитории CVS.
---
"Vyroba umelych lidi, slecno, je tovarni tajemstvi."
Ну а я умею клонировать репозитории CVS.ну с CVS, видимо, вообще трудно работать из-за того, что она версионирует отдельные файлы, а не проект. Может, конечно, это вопрос привычки, но моей первой системой контроля версий был TFS, потом пришлось некоторое время пользоваться VSS и я был очень доволен, когда перелил всю историю в репозиторий SVN: VSS вообще трудно воспринималась из-за отсутствия понятия единого номера ревизии для всего проекта.
> ну с CVS, видимо, вообще трудно работать из-за того,
> что она версионирует отдельные файлы, а не проект.
Это, мягко говоря, неправда.
Чаще наоборот: со всякими новомодными git и прочим "фоссилом"
трудно работать именно потому, что там трудно откатывать
изменения в отдельных модулях или файлах и получать при этом
более или менее разумные результаты.
Да! Когда доходит до общения с инженерами, то вообще начинается
весело: у них же нет понятия "версии" вообще! Они пишут что-то
нечитаемое и непроизносимое, причём называют это "номером."
Как-нибудь попроси инженера прочитать такой "номер" по радио.
Узнаешь про себя много нового.
Такое впечатление, что у программистов крыша совсем съехала,
и они переселились в какую-то иную реальность, где Брянск
и прочие аномалии.
---
"Мы диалектику учили не по Гегелю.
Бряцанием боёв она врывалась в стих..."
> что она версионирует отдельные файлы, а не проект.
Это, мягко говоря, неправда.
Чаще наоборот: со всякими новомодными git и прочим "фоссилом"
трудно работать именно потому, что там трудно откатывать
изменения в отдельных модулях или файлах и получать при этом
более или менее разумные результаты.
Да! Когда доходит до общения с инженерами, то вообще начинается
весело: у них же нет понятия "версии" вообще! Они пишут что-то
нечитаемое и непроизносимое, причём называют это "номером."
Как-нибудь попроси инженера прочитать такой "номер" по радио.
Узнаешь про себя много нового.
Такое впечатление, что у программистов крыша совсем съехала,
и они переселились в какую-то иную реальность, где Брянск
и прочие аномалии.
---
"Мы диалектику учили не по Гегелю.
Бряцанием боёв она врывалась в стих..."
нечитаемое и непроизносимоеgit help tag
>> нечитаемое и непроизносимое
> git help tag
Предлагается написать костыль, который будет при каждом коммите
приделывать номер версии a la Subversion?
Я-то напишу, только толку-то?
Этим надо при разработке было заниматься,
только это ведь думать надо уметь.
Вальтер Тихий, вот, умел.
---
"Унивеpситет pазвивает все способности, в том числе --- глупость."
> git help tag
Предлагается написать костыль, который будет при каждом коммите
приделывать номер версии a la Subversion?
Я-то напишу, только толку-то?
Этим надо при разработке было заниматься,
только это ведь думать надо уметь.
Вальтер Тихий, вот, умел.
---
"Унивеpситет pазвивает все способности, в том числе --- глупость."
Увольте-сс, зачем при каждом. При каждом необходимом.
git describe
> Увольте-сс, зачем при каждом. При каждом необходимом.
То есть промежуточные версии нумеровать не надо?
---
...Я работаю антинаучным аферистом...
То есть промежуточные версии нумеровать не надо?
---
...Я работаю антинаучным аферистом...
Ну и как это поможет?
---
...Я работаю антинаучным аферистом...
---
...Я работаю антинаучным аферистом...
А для промежуточных и sha1 сойдёт. Любое достаточно непромежуточное можно и удостоить тэга, или ветки, по ситуации. Как душе угодно.
> А для промежуточных и sha1 сойдёт.
Осталось только понять, как определять что промежуточное, а что нет,
ну и концептуальный вопрос: а зачем тогда вообще коммитить промежуточные
версии, не имеющие самостоятельного значения?
> Любое достаточно непромежуточное можно и удостоить тэга, или ветки, по ситуации.
> Как душе угодно.
Вообще-то, народ нумерует версии не просто так, а для того,
чтобы на них можно было по-человечески ссылаться.
То есть, чтобы не говорить "это было на чертеже ещё в том варианте
проекта, когда до узла коммутации ещё E1, но башню уже передвинули,"
а чтобы сказать, например, "в пятнадцатом варианте проекта."
И чтобы можно было просто сравнивать. Например, чтобы было очевидно,
что в прошивке 6.66 скорее всего меньше зла, чем в прошивке 6.13,
а прошивка 5.45 вообще относится к предыдущему проекту "железа."
Если ты предлагаешь хранить черновики, то тут сразу же возникает
разумный вопрос: если они более не имеют никакого значения, то
зачем их вообще хранить, а если они что-то значат, то почему у
них какая-то аномальная нумерация, на которую почти невозможно
сослаться?
---
"Унивеpситет pазвивает все способности, в том числе --- глупость."
Осталось только понять, как определять что промежуточное, а что нет,
ну и концептуальный вопрос: а зачем тогда вообще коммитить промежуточные
версии, не имеющие самостоятельного значения?
> Любое достаточно непромежуточное можно и удостоить тэга, или ветки, по ситуации.
> Как душе угодно.
Вообще-то, народ нумерует версии не просто так, а для того,
чтобы на них можно было по-человечески ссылаться.
То есть, чтобы не говорить "это было на чертеже ещё в том варианте
проекта, когда до узла коммутации ещё E1, но башню уже передвинули,"
а чтобы сказать, например, "в пятнадцатом варианте проекта."
И чтобы можно было просто сравнивать. Например, чтобы было очевидно,
что в прошивке 6.66 скорее всего меньше зла, чем в прошивке 6.13,
а прошивка 5.45 вообще относится к предыдущему проекту "железа."
Если ты предлагаешь хранить черновики, то тут сразу же возникает
разумный вопрос: если они более не имеют никакого значения, то
зачем их вообще хранить, а если они что-то значат, то почему у
них какая-то аномальная нумерация, на которую почти невозможно
сослаться?
---
"Унивеpситет pазвивает все способности, в том числе --- глупость."
чтобы на них можно было по-человечески ссылатьсяС чего и начинали. git tag существует в первую очередь для этого.
почти невозможноgit help rev-parse
зачем тогда вообще коммитить промежуточныеSave early, save often ;]
версии, не имеющие самостоятельного значения?
>> чтобы на них можно было по-человечески ссылаться
> С чего и начинали. git tag существует в первую очередь для этого.
Начали с того, что это должно быть сразу и по умолчанию,
а не требовать отдельных телодвижений. Даже в SCCS это есть.
---
"Унивеpситет pазвивает все способности, в том числе --- глупость."
> С чего и начинали. git tag существует в первую очередь для этого.
Начали с того, что это должно быть сразу и по умолчанию,
а не требовать отдельных телодвижений. Даже в SCCS это есть.
---
"Унивеpситет pазвивает все способности, в том числе --- глупость."
>> почти невозможно
> git help rev-parse
Да-а, тяжёлый случай.
Ты сколько в настоящих долгих проектах проработал?
Вот именно это и называется "почти невозможно:" оно возможно
только в некоторых специально созданных условиях.
Ты никогда ничего на тестирование не отправлял? Всегда метишь?
А вот некоторые умудряются не пометить. По разным причинам:
из-за спешки, из-за халатности, из-за лени,--- не важно.
Объясни, как какой-нибудь инженер, у которого есть только
ноутбук с виндой, рабочей документацей и терминальной программой,
должен определить, что же за прошивка в приборе перед ним?
Связываться с программистом чёрт знает где, чтобы он эту SHA1 "пробил?"
Представь, что у него из работающих средств связи есть только
радиостанция для связи с ещё одним таким же инженером.
Представь, что все программисты сейчас отсыпаются по поводу субботы,
разбежались по любовницам, семьям, дачам и проч.
Или ты думаешь, что в жизни всё всегда ровно и гладко?
---
"Narrowness of experience leads to narrowness of imagination."
> git help rev-parse
Да-а, тяжёлый случай.
Ты сколько в настоящих долгих проектах проработал?
Вот именно это и называется "почти невозможно:" оно возможно
только в некоторых специально созданных условиях.
Ты никогда ничего на тестирование не отправлял? Всегда метишь?
А вот некоторые умудряются не пометить. По разным причинам:
из-за спешки, из-за халатности, из-за лени,--- не важно.
Объясни, как какой-нибудь инженер, у которого есть только
ноутбук с виндой, рабочей документацей и терминальной программой,
должен определить, что же за прошивка в приборе перед ним?
Связываться с программистом чёрт знает где, чтобы он эту SHA1 "пробил?"
Представь, что у него из работающих средств связи есть только
радиостанция для связи с ещё одним таким же инженером.
Представь, что все программисты сейчас отсыпаются по поводу субботы,
разбежались по любовницам, семьям, дачам и проч.
Или ты думаешь, что в жизни всё всегда ровно и гладко?
---
"Narrowness of experience leads to narrowness of imagination."
>> зачем тогда вообще коммитить промежуточные
>> версии, не имеющие самостоятельного значения?
> Save early, save often ;]
"Save" /= "commit."
Можно и по поводу идиотского подхода "commit often" поспорить:
если ты постоянно коммитишь всякую пургу, которая ломает даже сборку,
то как ты ищешь, которая из версий наконец-то соберётся?
Линейным поиском в обе стороны? Или ты как-то постоянно вручную(!)
метишь те версии, которые собираются?
---
"Narrowness of experience leads to narrowness of imagination."
>> версии, не имеющие самостоятельного значения?
> Save early, save often ;]
"Save" /= "commit."
Можно и по поводу идиотского подхода "commit often" поспорить:
если ты постоянно коммитишь всякую пургу, которая ломает даже сборку,
то как ты ищешь, которая из версий наконец-то соберётся?
Линейным поиском в обе стороны? Или ты как-то постоянно вручную(!)
метишь те версии, которые собираются?
---
"Narrowness of experience leads to narrowness of imagination."
Разумеется, нет. в действительности всё не так, как на самом деле. Лично моя действительность такова, что в ней нету инженеров с радиостанциями и прошивок с ревизиями, но есть различные ситуации, в которых именно git максимизирует локальное счастье. И я вопреки ожиданиям вовсе не стремлюсь утверждать единственную верность и правильность.
На смену svn идет... svn 1.7! Все .svn папки планируют заменить одним файлом с sqlite базой данных, что должно значительно его ускорить и позволить добавить такие давно ожидаемые фичи, как rename tracking.
На смену svn идет... svn 1.7! Все .svn папки планируют заменить одним файлом с sqlite базой данных, что должно значительно его ускорить и позволить добавить такие давно ожидаемые фичи, как rename tracking.А вот это уже интересно.
Бальзам на душу просто.
А под виндой локально что поднять ?
А под виндой локально что поднять для вордовских файлов ?довольно легко, есть Visual SVN Server. Но какой в этом смысл без поддержки со стороны ворда?
А под виндой локально что поднять для вордовских файлов ?У нтфс же кажется (могу врать) искаропке сейчас есть версионирование?
В любом случае, какой-нибудь шарепоинт как раз умеет версионировать доки.
ШареПоинт хранилище на локальном компе можно поднять ?
довольно легко, есть Visual SVN Server.
Если у тебя серверная версия винды и достаточно памяти 
Зависит от того, что тебе нужно.
я предпочитаю Bazaar (на нём launchpad работает) или в крайнем случае Mercural
Git не предназначен для проектов с большим числом разработчиков, увы
я предпочитаю Bazaar (на нём launchpad работает) или в крайнем случае Mercural
Git не предназначен для проектов с большим числом разработчиков, увы
У нтфс же кажется (могу врать) искаропке сейчас есть версионирование?в UI это только в 7ке заметно
Под виндой тот же SVN, а в качестве клиента использовать Tortoise SVN, который для сравнения документов вызывает тот же ворд, который умеет сравнивать.
Git не предназначен для проектов с большим числом разработчиков, увыА это можно как-то проаргументировать?
На Win Xp prof работать будет с 2003 -им Вордом ?
Под виндой тот же SVN, а в качестве клиента использовать Tortoise SVN, который для сравнения документов вызывает тот же ворд, который умеет сравнивать.
Поставь и посмотри. Делов-то на 15 минут.
Да, отпишись потом, пожалуйста, чтобы знать, работает ли.
Оставить комментарий
stm7884696
В одном из недавних тредов проскочила фраза, что svn нынче уже не моден и устарел.А что пришло ему на замену?