SVN

http://tinyurl.com/3o58enl

Начни лучше сразу с github.com

man git

http://svnbook.red-bean.com/index.ru.html

>>Надо ли что-то устанавливать на сервере?

да, Git

svn add *

Каждый раз после

svn commit
svn up

svn checkout <server-url>

*только при наличии доступа. смотри также мануалы по svn и тысячи страниц одного и того же howto по svn.

п.с. git is better man. infa 100%.

SVN устаревшее говно, Git распиаренное говно. Рулит только Mercurial.

{hg,git} лучше, потому-что я использую {hg,git}

//fxd

ваши гит и меркуриал поделки для школоло.
Нормальные конторы хостят свои проекты исключительно на SVN.
Смотрим на тот же гугл.
/thread

>svn commit

svn up

я бы за такое убивал.
правильно:
svn up
svn commit

И эти люди еще советуют систему контроля версий.

я просто отсавлю это здесь

> Нормальные конторы хостят свои проекты исключительно на SVN.

Смотрим на тот же гугл.

Ололо, школоло ;) Гугл _свои_ поделки (внутренние проекты) хостит на Perforce. А на code.google.com - на выбор SVN и Mercurial (про git не знаю).

я ему git посоветовал если чё. писатель не читатель?

правильно apt-get install git

//fxd

>Начни лучше сразу с github.com
и выверни себе мозги.

> правильно:

svn up

svn commit

...и ты закоммитил код, который даже не проверил (конечно, это только отчасти твоя вина, но всё же).

да, ты прав.

man hg.

> Надо ли что-то устанавливать на сервере?

svnserve

> хочу, чтобы то, что я разрабатываю у себя на компе автоматически обновлялось у меня на сервере в интернете.

man rsync

man crontab

;)

Смотрим на тот же гугл.

А в Яндексе CVS юзают. И что?

man эмпирическая индукция

и ты закоммитил код, который даже не проверил

может у него там pre-update hook стоит с тестами :)

>> и ты закоммитил код, который даже не проверил

может у него там pre-update hook стоит с тестами :)

А смысл в pre-update проверке? Она пройдет успешно. Вот post-update проверка может сфейлить, но уже будет поздно - состояние рабочей копии, предшествовавшее update, потеряно. И даже не факт, что его можно восстановить.

man hg

fixed

на самом деле мы используем pre-tested commits, но это не суть важно

А в Яндексе CVS юзают. И что?

не правда, cvs сто лет как не юзают

чтоб таких проблем не было, надо юзать нормальные системы контроля версий

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

Неосилятор детектед.

Там куча нелогичностей из-за которых надо постоянно лезть в ман. Оно мне надо?

Пример хотя бы приведи. А то как-то голословно получается.

ну например, revert делается checkout'ом

А смысл в pre-update проверке?

В смысле pre-commit. Я себе это так представляю: где-то рядом есть свежий checkout на который натягивается патч. Если тесты после этого проходят то патч накладывается на основное дело.

Признаюсь, так не делал, но читал :)

> Пример

Вот нафига там dangling commits и dangling trees? Причём везде природа этого явления объясняется очень расплывчато. И то это сейчас по нему много чего гуглится, а пару лет назад было написано «всё нормально, вам это не нужно». А у мну туда здоровенный commit попал: http://www.linux.org.ru/forum/development/3649545

не правда, cvs сто лет как не юзаю

А они недавно перешли наверное? Год назад к нам в комманду пришел чел из яндекса, который и рассказывал, что у них что-то на cvs хранится (то ли поиск, то ли биллинг).

Используется всё (svn, mercurial, git, ...), но в основном почти все проекты на svn. История в svn достаточно древняя. Может что-то совсем совсем древнее и осталось на cvs, но я не в курсе.

перевод старый использованию не подлежит

в яндексе уже давно не юзают cvs юзают svn

репозиторий перетягивали из cvs в svn вместе с историей отсюда и ваше заблуждение

ну например, revert делается checkout'ом

Пц, SVNшики набежали. Запомни: в git checkout делается checkout'ом! Если ты модифицировал файл, то для того, чтобы вернуть его в исходное состояние (которое HEAD), тебе его надо (ВНЕЗАПНО!) взять из HEAD. Взять из HEAD - это checkout. Нелогичность у тебя в голове, потому что ты ожидаешь что гит будет SVN-ом.

> чтобы вернуть его в исходное состояние (которое HEAD), тебе его надо (ВНЕЗАПНО!) взять из HEAD. Взять из HEAD - это checkout. Нелогичность у тебя в голове, потому что ты ожидаешь что гит будет SVN-ом.

Уважаемые зрители, только что вы наблюдали отличный пример промывания мозгов.

Уважаемые зрители, только что вы наблюдали отличный пример промывания мозгов.

Уважаемые зрители, только что вы наблюдали отличный пример тролля.

Ну давай, фигли, расскажи мне, что в мною сказанном нелогично.

отличный пример промывания мозгов

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

> Ну давай, фигли, расскажи мне, что в мною сказанном нелогично.

Оно предельно логично. Только логика за ним такова: «ага, в SVN есть revert... таак, что он делает? ага, откатывает файл к определенной ревизии... что за лохи, это же всё равно, что checkout». Я не говорю, что это твоя логика, но весь git сделан именно по ней. Это реально грустно. В результате получена система, главным отличием которой от существующих является идиотский набор команд, продвигаемая специфическим пиаром и трюками за гранью фола (см. историю перехода xorg на git).

Чтобы быстро ознакомиться с принципами работы — достаточно. А остальное в оригинальной документации.

tailgunner недавно таблицу сравнения давал где на каждую простую и интуитивную команду hg шла портянка команд git'а. это говорит многое о нелогичности git'а

что интересно, в git тоже есть revert, но то что он делает в нормальных системах зовут backout'ом :)

Кстати, я пока не понял чем отличается git fetch от git pull

Кстати, я пока не понял чем отличается git fetch от git pull

один только скачивает изменения, а второй их ещё и накатывает. Т.е. git pull это git fetch + git merge.

> tailgunner недавно таблицу сравнения давал

Вот эта? :) https://github.com/sympy/sympy/wiki/Git-hg-rosetta-stone