OS>> — Разработка ведётся на Visual Studio 2005
WH>Практика показывает что интеграция SVN со студией не нужна.

Можно эту фразу прокомментировать? Как раз на днях озаботились вопросом, на что переехать с VSS + SourceOffSite, ибо SoS задолбал

Пока рассматриваемся к Vault, но на Subversion тоже смотрел. Всё бы хорошо, но именно отсутствие живого (а не за 2004 год) SCC провайдера и насторожило. Пробовал ещё Ankh, но он не SCC, предлагает другой принцип работы, а значит сложно будет убедить кого из проектной группы, что имеет смысл переучиваться.

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

Здравствуйте, Ego, Вы писали:

Ego>С черепахой я вообще не понял, как это может быть удобным? Поэтому и спрашиваю, что значит не нужна интеграция?

Значит не нужна.

Ego> Ведь иначе перед каждым изменением надо лезь вручную check outить файлы?

В SVN вобще нет операции checkout

Ego> Или я что-то не догоняю, может принцип работы другой?

Именно

Ego>> Ведь иначе перед каждым изменением надо лезь вручную check outить файлы?
AVK>В SVN вобще нет операции checkout
А как это?

На cvs было:
— получаешь в рабочий каталог весь проект;
— чекаутишь те файлы, которые будешь менять;
— меняешь файлы;
— чекинишь измененное.

А тут как?

Здравствуйте, O-Sam, Вы писали:

OS>На cvs было:
OS>- получаешь в рабочий каталог весь проект;
OS>- чекаутишь те файлы, которые будешь менять;
OS>- меняешь файлы;
OS>- чекинишь измененное.

OS>А тут как?

Предположим, на машине source-server работает svnserve. Вы, в контекстном меню Проводника выбираете SVN Checkout.... В поле URL of repository вводите, например, svn://source-server/project-name/trunk а в Checkout directory — d:\projects\project-name. По умолчанию забирается т.н. Head Revision (последняя ревизия, в общем). Нажимаете OK, ждете.

В результате в папке d:\projects\project-name у вас будет Working Copy всего проекта. Запускаете Студию, начинаете работать. Меняете код, добавляете классы — все как обычно (переименование файлов немного сложнее). Теперь требуется Commit. Правой педалью нажимаете на папку d:\projects\project-name, там — Commit. Появляется окно со списком измененных файлов. Там же можно добавить новые файлы (не так уродски, как в VSS, а просто галочку поставить надо). Все. Пишете комментарий к коммиту и нажимаете ОК. Теперь два пути. Либо все закоммитилось нормально, либо кто-то уже что-то изменил и у вас на диске осталасьс "старая" рабочая копия. Опять правой тапкой, TortoiseSVN — Update. Разруливаете конфликты, коммитите заново.

Вот примерно так

дравствуйте, O-Sam, Вы писали:

AVK>>В SVN вобще нет операции checkout
OS>А как это?

OS>На cvs было:
OS>- получаешь в рабочий каталог весь проект;
OS>- чекаутишь те файлы, которые будешь менять;

Это было не обязательно

OS>- меняешь файлы;
OS>- чекинишь измененное.

OS>А тут как?

Обыкновенно. Меняешь все что тебе надо, подом делаешь commit.

Здравствуйте, WolfHound, Вы писали:

WH>

WH>"C:\Program Files\Subversion\bin\svnserve.exe " -d -r "d:\svn_root"
WH>

Вот только с шифрованием в таком варианте ИМХО будет плохо.
Я на FreeBSD-то повозился что-бы толковую работу с openssh наладить (да и все-равно все не слишком прямо там сделано). А на виднах уж и вообще...

Ego>С черепахой я вообще не понял, как это может быть удобным? Поэтому и спрашиваю, что значит не нужна интеграция?
AVK>Значит не нужна.

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

AVK>>>В SVN вобще нет операции checkout
OS>>- чекаутишь те файлы, которые будешь менять;
AVK>Это было не обязательно

Предвижу тут проблемы, по крайней мере в нашей команде, годами привыкавшей к VSS. "чекаутишь те файлы, которые будешь менять" -- это просто будет забываться, так как привыкли, что студия это делает автоматом сама. Т.е. для "нормальной" работы перед любым ковырянием в проекте надо целиком проект взять на себя? Не говорю, что это неубобно, просто придётся переучивать много людей... Что если кто-то забыл "зажать" на себя файл, как это будет видно? И не совсем понятно, как с .cproj файлами быть.

Здравствуйте, Ego, Вы писали:

Ego>Предвижу тут проблемы, по крайней мере в нашей команде, годами привыкавшей к VSS. "чекаутишь те файлы, которые будешь менять" -- это просто будет забываться, так как привыкли, что студия это делает автоматом сама. Т.е. для "нормальной" работы перед любым ковырянием в проекте надо целиком проект взять на себя?

Такое ощущение что ты не читаешь что тебе пишут. В SVN нет операции "проект взять на себя". В любой момент ты можешь изменить в рабочей копии любой файл из любой программы, не выполняя никаких дополнительных операций для этого.

AVK>Такое ощущение что ты не читаешь что тебе пишут. В SVN нет операции "проект взять на себя". В любой момент ты можешь изменить в рабочей копии любой файл из любой программы, не выполняя никаких дополнительных операций для этого.

Спасибо за вежливый ответ. Меня смутила фраза выше: "Вы, в контекстном меню Проводника выбираете SVN Checkout...."

Здравствуйте, Ego, Вы писали:

Ego>Меня смутила фраза выше: "Вы, в контекстном меню Проводника выбираете SVN Checkout...."

Это нужно сделать ровно 1 раз для создания рабочей копии. SVN Checkout != VSS Checkout. А вобще стоит почитать документацию к TortoiseSVN. Там все довольно коротко и простым языком описано.

Здравствуйте, PPA, Вы писали:

E>>Более того, если у apache настроить gzip-ование трафика, то вообще все очень шустро работает. Тем более в локалке.

PPA>а можно подробнее как оно настраивается?

Не я занимался настройкой Apache (у нас Apache 2.0.*), но вроде бы, все вылилось в добавление в httpd.conf двух строк:

LoadModule deflate_module modules/mod_deflate.so

SetOutputFilter DEFLATE

Подробнее про mod_deflate из Apache 2 можно почитать здесь: http://httpd.apache.org/docs/2.0/mod/mod_deflate.html
А про mod_deflate для Apache 1.3: http://sysoev.ru/mod_deflate/