Re[6]: Что лучше SVN или MS Team Foundation ? - Средства разработки

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

bnk>Можете пояснить, что вы называете "нормальным толстым гуёвым клиентом", а главное, нафига он вообще нужен?

Нормальный толстый гуёвый клиент — это, например, как у StarTeam.
Нужен он для того, чтобы:

1) не захламлять драгоценную программистскую память несколькими десятками ключей командной строки
2) выполнять операции с VCS парой нажатий клавиш мышки, а не двадцатью нажатиями клавиш клавиатуры, тем самым экономя кучу времени

bnk>Ну чем например плох Tortoise?

В первую очередь, своими бедными характеристиками в плане usability. Навкидку, вспоминаются следующие use-case:

1) Я смотрю историю файла, пытаясь дихотомией найти ревизию, когда в нём появилось некоторое изменение. Tortoise не выводит все ревизии в виде списка — только кусочками по сотне. Это уже удар по дихотомии, хотя ладно — терпимо. Дальше. В первой колонке выводится номер ревизии в репозитории, а порядковый номер в списке (который не хранится в VCS), к которому было бы удобно привязаться при поиске, — не выводится нигде.

2) Я сейчас довольно часто забываю положить в репозиторий некоторые файлы, которые я добавляю в проект. Файл в проект добавил, а svn add сделать забыл. Клиент StarTeam, тем временем, умеет показывать unversioned files, причём умеет их очень хорошо фильтровать. Фильтры есть общие для всех пользователей, и индивидуальные для конкретного, их можно ставить для каждой папки свои, можно наследовать. Более того — для того, чтобы посмотреть на появившиеся unversioned files, в ST не надо нажимать никаких лишних кнопок. Со ST я крайне редко забывал положить в репозиторий добавленные файлы. TFS тоже помогает не забыть положить в репозиторий добавленные файлы.

3) Если я начал редактировать некоторый файл, а потом решил его переименовать, то svn rename меня посылает.

4) Очень часто мне хочется поглядеть, насколько лежащий у меня локально проект устарел по сравнению с репозиторием, какие конфликты появились, какие файлы поменяли коллеги. Tortoise SVN _никак_ не маркирует в проводнике out of date файлы (насколько я знаю). В tortoise нет возможности посмотреть список невзятых из репозитория файлов. А между тем клиент ST всё это позволяет сделать — опять таки — нажатием одной кнопки. В нём я вижу 6 (максимум)открывающихся списков файлов — Current (up-to-date), Missing, Unversioned (с применёнными интеллектуальными фильтрами это те файлы, которые я должен не забыть добавить в version control), Out of date, Modified, Pending for Merge.

В-общем, перечислять можно долго.

... и это ещё не считая того, что я просто не видел, как в Tortoise работает visual merge — обычно командной строки хватало...

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

bnk>>Ну чем например плох Tortoise?

J>В первую очередь, своими бедными характеристиками в плане usability.

IMHO, это просто смешно.
Лично мне "в плане usability" Tortoise представляется ОЧЕНЬ удачной.

J>1) Я смотрю историю файла, пытаясь дихотомией найти ревизию, когда в нём появилось некоторое изменение. Tortoise не выводит все ревизии в виде списка — только кусочками по сотне. Это уже удар по дихотомии, хотя ладно — терпимо. Дальше. В первой колонке выводится номер ревизии в репозитории, а порядковый номер в списке (который не хранится в VCS), к которому было бы удобно привязаться при поиске, — не выводится нигде.

Не понял проблемы.
Для того чтобы найти в какой ревизии появилось изменение, есть пунктик меню "Blame..".
Никаких дихотомий.

J>2) Я сейчас довольно часто забываю положить в репозиторий некоторые файлы, которые я добавляю в проект. Файл в проект добавил, а svn add сделать забыл. Клиент StarTeam, тем временем, умеет показывать unversioned files, причём умеет их очень хорошо фильтровать. Фильтры есть общие для всех пользователей, и индивидуальные для конкретного, их можно ставить для каждой папки свои, можно наследовать. Более того — для того, чтобы посмотреть на появившиеся unversioned files, в ST не надо нажимать никаких лишних кнопок. Со ST я крайне редко забывал положить в репозиторий добавленные файлы. TFS тоже помогает не забыть положить в репозиторий добавленные файлы.

Меня например этот "Pending checkins" нервирует.
Просто когда делаете "Commit", смотрите список файлов, которые еще не в репозитории, и добавляете их (ставите на них галочки).
И еще, какой нафик svn add ?? Напомню, что речь идет о Tortoise SVN, GUI-клиенте, встраивающемся в Explorer.
Фильтры по типу файла или конкретному файлу в Tortoise делаются выделением файлов и нажатием пунктика меню "Add to ignore list".
Эти фильтры сохраняются в репозитории, само собой.

J>3) Если я начал редактировать некоторый файл, а потом решил его переименовать, то svn rename меня посылает.

А меня вот не посылает. Странно, да?

J>4) В tortoise нет возможности посмотреть список невзятых из репозитория файлов

Это просто неправда.
Пунктик меню "Check for modifications", кнопочка "Check repository" делает ровно это —
выводит список файлов, которые изменились по сравнению с рабочей копией.

J>... и это ещё не считая того, что я просто не видел, как в Tortoise работает visual merge — обычно командной строки хватало...

Я лично пользуюсь Araxis-ом, легко интегрируется с Tortoise.

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

bnk>IMHO, это просто смешно.
bnk>Лично мне "в плане usability" Tortoise представляется ОЧЕНЬ удачной.

Значит, следует признать, что по этому вопросу бывают разные мнения :-)
Для интереса — Вы со StarTeam работали сколь-нибудь существенное время?

J>>1) Я смотрю историю файла, пытаясь дихотомией найти ревизию, когда в нём появилось некоторое изменение. Tortoise не выводит все ревизии в виде списка — только кусочками по сотне. Это уже удар по дихотомии, хотя ладно — терпимо. Дальше. В первой колонке выводится номер ревизии в репозитории, а порядковый номер в списке (который не хранится в VCS), к которому было бы удобно привязаться при поиске, — не выводится нигде.
bnk>Не понял проблемы.
bnk>Для того чтобы найти в какой ревизии появилось изменение, есть пунктик меню "Blame..".
bnk>Никаких дихотомий.

Принято. Хотя тот факт, что данная фича совершенно undiscoverable (интересно, какое отношение глагол "Обвинять" имеет к тому, что делает данная фича?) — недоработка черепашки :)

J>>2) Я сейчас довольно часто забываю положить в репозиторий некоторые файлы, которые я добавляю в проект. Файл в проект добавил, а svn add сделать забыл. Клиент StarTeam, тем временем, умеет показывать unversioned files, причём умеет их очень хорошо фильтровать. Фильтры есть общие для всех пользователей, и индивидуальные для конкретного, их можно ставить для каждой папки свои, можно наследовать. Более того — для того, чтобы посмотреть на появившиеся unversioned files, в ST не надо нажимать никаких лишних кнопок. Со ST я крайне редко забывал положить в репозиторий добавленные файлы. TFS тоже помогает не забыть положить в репозиторий добавленные файлы.

bnk>Меня например этот "Pending checkins" нервирует.
Зато можно instantly что-нибудь откатить.

bnk>Просто когда делаете "Commit", смотрите список файлов, которые еще не в репозитории, и добавляете их (ставите на них галочки).
Как я понимаю, речь идёт о том, чтобы на каталоге мышой выбрать пункт меню "Add"?
Принято.

bnk>И еще, какой нафик svn add ?? Напомню, что речь идет о Tortoise SVN, GUI-клиенте, встраивающемся в Explorer.
Если речь идёт о Tortoise, то следует вспомнить и о том, что он довольно тормозной.
Например, svn update/commit из консоли у меня работают на порядки быстрее, чем из контекстного меню Tortoise.

bnk>Фильтры по типу файла или конкретному файлу в Tortoise делаются выделением файлов и нажатием пунктика меню "Add to ignore list".
bnk>Эти фильтры сохраняются в репозитории, само собой.
Принято, спасибо.

J>>3) Если я начал редактировать некоторый файл, а потом решил его переименовать, то svn rename меня посылает.
bnk>А меня вот не посылает. Странно, да?

Ещё раз. Берём файл, модифицируем его, потом говорим svn rename <нынешнее имя файла> <желаемое имя файла>
В консоли видим:

svn: Use --force to override this restriction
svn: Move will not be attempted unless forced
svn: <нынешнее имя файла> has local modifications

J>>4) В tortoise нет возможности посмотреть список невзятых из репозитория файлов

bnk>Это просто неправда.
bnk>Пунктик меню "Check for modifications", кнопочка "Check repository" делает ровно это —
bnk>выводит список файлов, которые изменились по сравнению с рабочей копией.

Просто ужасающе non-discoverable. К тому же, увидеть 6 раскрывающихся списков, как я понимаю, не получится.
Смотреть history instantly — довольно затруднительно — надо жать правую кнопку мыши, выбирать в меню show log, и ждать некоторое время, пока соизволит открыться отдельное окошко.
Тем не менее, спасибо.

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

bnk>>Лично мне "в плане usability" Tortoise представляется ОЧЕНЬ удачной.

J>Значит, следует признать, что по этому вопросу бывают разные мнения

J>Для интереса — Вы со StarTeam работали сколь-нибудь существенное время?

Я работал. После TortoiseSVN хочется плеваться.

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

bnk>>>Лично мне "в плане usability" Tortoise представляется ОЧЕНЬ удачной.
J>>Для интереса — Вы со StarTeam работали сколь-нибудь существенное время?
К>Я работал. После TortoiseSVN хочется плеваться.

А можно поподробнее?
Что именно Вас не устраивает в ST, что устраивало в TortoiseSVN?

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

J>Здравствуйте, Константин, Вы писали:

bnk>>>>Лично мне "в плане usability" Tortoise представляется ОЧЕНЬ удачной.
J>>>Для интереса — Вы со StarTeam работали сколь-нибудь существенное время?
К>>Я работал. После TortoiseSVN хочется плеваться.

J>А можно поподробнее?
J>Что именно Вас не устраивает в ST, что устраивало в TortoiseSVN?

Рассматриваем вопросы связанные с контролем версий, ok?

1. Отличия основанные на особенности системы контроля версий
— Атомарность commit.
— Версионность всего репозитория. Вношу изменения в несколько файлов сразу. Это рассматривается как один change. Мне не нужно потом отлавливать какие 20 файлов в каких каталогах я поменял, чтобы переименовать i в j.
— Беспроблемное удаление/добавление файлов/каталогов.
— Прозрачная работа с branch/tag
— Возможность иметь несколько рабочих копий (не очень важно, но иногда приятно)

2. Отличия в GUI
— легче добавлять ignore файлы. Да и просто commit делать как-то удобней
— "красивые картинки". Я сразу в explorer вижу что у меня поменялось.
— легко могу посмотреть историю, связанную с конкретным каталогом/файлом
— опять-же branch/tag теперь реально использовать в работе.

3. Other
— как ни странно, но SVN и TSVN лучше документирован

Список не претендует на полноту. Что-то наверное субъективно.

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

К>Рассматриваем вопросы связанные с контролем версий, ok?

К>1. Отличия основанные на особенности системы контроля версий
К>- Атомарность commit.

Есть в ST начиная с какой-то версии (в 2006 точно есть, в 6.0 точно нет. когда появилось — сложно сказать)

К>- Версионность всего репозитория. Вношу изменения в несколько файлов сразу. Это рассматривается как один change. Мне не нужно потом отлавливать какие 20 файлов в каких каталогах я поменял, чтобы переименовать i в j.

Опять-таки — есть в последних версиях.

К>- Беспроблемное удаление/добавление файлов/каталогов.

С этим в ST не было абсолютно никаких проблем даже в версии 4.2 :-)

К>- Прозрачная работа с branch/tag

Что значит "прозрачная работа"?
В ST есть view/label, это те же branch/tag с точностью до терминологии.
И, к слову сказать, по-моему из всех систем контроля версий только в ST есть такая замечательная фича, как возможность создавать плавающие ветки.
Плавающая ветка — это когда выпустили мы релиз, и отбранчили его в плавающую ветку. Потом через небольшое время после релиза коммитим какие-то изменения в зарелиженную ветку. Если ветка плавающая, то изменения при этом автоматически коммитятся в trunk при условии, что у данного элемента в trunk не было изменений после бранчевания. Иными словами, фактически branch для каждого файла создаётся on demand, в тот момент, когда этот файл впервые после команды branch модифицируется в trunk'e.

К>- Возможность иметь несколько рабочих копий (не очень важно, но иногда приятно)

Не припомню никаких проблем с этим в ST.

К>2. Отличия в GUI
К>- легче добавлять ignore файлы. Да и просто commit делать как-то удобней

Субъективно. Мне вот нравится смотреть состояние проекта, 6 закрывающихся списков. Возможность сделать так, чтобы история появлялась в нижнем pane в тот момент, когда я файл кликаю мышкой, а не в отдельном окне через n минут после того, как я продерусь через черепашьи контекстные меню...

К>- "красивые картинки". Я сразу в explorer вижу что у меня поменялось.

А тут можно нажать F5 и увидеть закрывающийся список с изменившимися файлами :-)

К>- легко могу посмотреть историю, связанную с конкретным каталогом/файлом

Это в ST проще, чем в TortoiseSVN. В TortoiseSVN нужно лезть в контекстное меню, в ST достаточно открыть вкладочку history, которая будет сама обновляться, если отселектировать другой элемент (файл\каталог).

К>- опять-же branch/tag теперь реально использовать в работе.

Ну уж, простите...

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

J>Здравствуйте, Константин, Вы писали:

К>>Рассматриваем вопросы связанные с контролем версий, ok?

J>Есть в ST начиная с какой-то версии (в 2006 точно есть, в 6.0 точно нет. когда появилось — сложно сказать)
Я работал с 6.0. Так что

К>>- Беспроблемное удаление/добавление файлов/каталогов.
J>С этим в ST не было абсолютно никаких проблем даже в версии 4.2

Хорошо, а как мне узнать: "Какие файлы/каталоги добавлялись/удалялись при добавлении фичи A?"

К>>- Прозрачная работа с branch/tag
J>Что значит "прозрачная работа"?
Branch, tag по сути своей являются просто каталогом в репозитории. При этом копирование внутри репозитория дешёвая операция.
Со всеми вытекающими последствиями. Очень легко понять и использовать.

J>Плавающая ветка — это когда выпустили мы релиз, и отбранчили его в плавающую ветку. Потом через небольшое время после релиза коммитим какие-то изменения в зарелиженную ветку. Если ветка плавающая, то изменения при этом автоматически коммитятся в trunk при условии, что у данного элемента в trunk не было изменений после бранчевания. Иными словами, фактически branch для каждого файла создаётся on demand, в тот момент, когда этот файл впервые после команды branch модифицируется в trunk'e.
Получается, что изменения в плавающей ветке могут потенциально сломать trunk? Я правильно понимаю, что такое возможно?
1. в trunk изменили a.cpp
2. в branch изменили a.cpp, a.h
Тогда в trunk изменится a.h но не a.cpp, что может быть плохо.
Если это так, я бы не стал использовать такую фичу. По мне поведение будет не интуитивно. Изменения в branch не должны ломать trunk.

К>>- Возможность иметь несколько рабочих копий (не очень важно, но иногда приятно)
J>Не припомню никаких проблем с этим в ST.
Ну как же. В "Folder properties" живёт "Working folder". Постоянно его переключать что-ли?

К>>- легче добавлять ignore файлы. Да и просто commit делать как-то удобней
J>Субъективно.
+1

J>Это в ST проще, чем в TortoiseSVN. В TortoiseSVN нужно лезть в контекстное меню, в ST достаточно открыть вкладочку history, которая будет сама обновляться, если отселектировать другой элемент (файл\каталог).
Ну и что мне показывается для каталога? Я хочу видеть историю изменений файлов из этого каталога. Я её вижу в TSVN, я её не вижу в StarTeam. А как мне быстро посмотреть, что делал в январе Ваня Иванов с подкаталогом Utils?

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

К>>>- Беспроблемное удаление/добавление файлов/каталогов.
J>>С этим в ST не было абсолютно никаких проблем даже в версии 4.2 :-)
К>Хорошо, а как мне узнать: "Какие файлы/каталоги добавлялись/удалялись при добавлении фичи A?"

Добавление — здесь спасёт поиск по комментарию.
Удаление... согласен. Принято.

К>>>- Прозрачная работа с branch/tag
J>>Что значит "прозрачная работа"?
К>Branch, tag по сути своей являются просто каталогом в репозитории. При этом копирование внутри репозитория дешёвая операция.
К>Со всеми вытекающими последствиями. Очень легко понять и использовать.

То, что Вы написали — это философия subVersion, и у меня в ней есть сомнения.
Например, не далее как сегодня наблюдали с коллегой следующую ситуацию. Коллега выкладывал потенциально опасное изменение, и хотел перед выкладыванием поставить tag. Всё, что он хотел — всего лишь запомнить номер ревизии, до которой придётся откатить некоторые файлы, если что. SubVersion же нам предлагает в этом случае сделать branch, мотивируя это тем, что branch — операция, имеющая константную трудоёмкость. Чем плох в данной ситуации branch? Тем, что в branch кто-то может что-то закоммитить, в том числе по ошибке. В метку, tag закоммитить ничего изначально нельзя. Получается, branch после создания нужно лочить. Это всё равно не спасает от того риска, что в него что-нибудь закоммитит владелец лока (или от того, что кто-нибудь стащит лок ключиком --force). В-общем, не ясно, почему мы не можем ПРОСТО ПРИСВОИТЬ ТЕКСТОВОЕ ИМЯ НЕКОТОРОЙ РЕВИЗИИ...

J>>Плавающая ветка — это когда выпустили мы релиз, и отбранчили его в плавающую ветку. Потом через небольшое время после релиза коммитим какие-то изменения в зарелиженную ветку. Если ветка плавающая, то изменения при этом автоматически коммитятся в trunk при условии, что у данного элемента в trunk не было изменений после бранчевания. Иными словами, фактически branch для каждого файла создаётся on demand, в тот момент, когда этот файл впервые после команды branch модифицируется в trunk'e.
К>Получается, что изменения в плавающей ветке могут потенциально сломать trunk? Я правильно понимаю, что такое возможно?
К>1. в trunk изменили a.cpp
К>2. в branch изменили a.cpp, a.h
К>Тогда в trunk изменится a.h но не a.cpp, что может быть плохо.
К>Если это так, я бы не стал использовать такую фичу. По мне поведение будет не интуитивно. Изменения в branch не должны ломать trunk.

В версиях ST, в которых не было атомарных коммитов, всё обстояло в точности так, как Вы сказали. По-моему, в нём нет ничего криминального — просто всегда нужно следить за тем, что пролезло в trunk, и всё. Benefits от этой фичи гораздо заметнее :-) Хотя зависит от проекта, конечно.

К>>>- Возможность иметь несколько рабочих копий (не очень важно, но иногда приятно)
J>>Не припомню никаких проблем с этим в ST.
К>Ну как же. В "Folder properties" живёт "Working folder". Постоянно его переключать что-ли?

Folder properties вообще, ИМХО, трогать не правильно. Working folder нужно назначать во view properties. Можно ли зачекаутить несколько views, я уже, признаться, не помню...

J>>Это в ST проще, чем в TortoiseSVN. В TortoiseSVN нужно лезть в контекстное меню, в ST достаточно открыть вкладочку history, которая будет сама обновляться, если отселектировать другой элемент (файл\каталог).
К>Ну и что мне показывается для каталога? Я хочу видеть историю изменений файлов из этого каталога. Я её вижу в TSVN, я её не вижу в StarTeam. А как мне быстро посмотреть, что делал в январе Ваня Иванов с подкаталогом Utils?

Принято. Хотя для файлов в ST сделано удобнее :)

СТ>Ну, собственно, таск/баг-менеджмент, планировании тасков по итерациям, автоматические билды — это всё там есть.

И еще много чего.

а можно его использовать для распределённой компиляции? как например IncrediBuild ?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

СТ>>Ну, собственно, таск/баг-менеджмент, планировании тасков по итерациям, автоматические билды — это всё там есть. :-) И еще много чего. :-)
_>а можно его использовать для распределённой компиляции? как например IncrediBuild ?

Нет.

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

К>>>>- Прозрачная работа с branch/tag
J>>>Что значит "прозрачная работа"?
К>>Branch, tag по сути своей являются просто каталогом в репозитории. При этом копирование внутри репозитория дешёвая операция.
К>>Со всеми вытекающими последствиями. Очень легко понять и использовать.
J>То, что Вы написали — это философия subVersion, и у меня в ней есть сомнения.
J>Например, не далее как сегодня наблюдали с коллегой следующую ситуацию. Коллега выкладывал потенциально опасное изменение, и хотел перед выкладыванием поставить tag. Всё, что он хотел — всего лишь запомнить номер ревизии, до которой придётся откатить некоторые файлы, если что. SubVersion же нам предлагает в этом случае сделать branch, мотивируя это тем, что branch — операция, имеющая константную трудоёмкость. Чем плох в данной ситуации branch? Тем, что в branch кто-то может что-то закоммитить, в том числе по ошибке. В метку, tag закоммитить ничего изначально нельзя. Получается, branch после создания нужно лочить. Это всё равно не спасает от того риска, что в него что-нибудь закоммитит владелец лока (или от того, что кто-нибудь стащит лок ключиком --force). В-общем, не ясно, почему мы не можем ПРОСТО ПРИСВОИТЬ ТЕКСТОВОЕ ИМЯ НЕКОТОРОЙ РЕВИЗИИ...
Отличие tag и branch всего лишь в правах доступа. tag это всего лишь read only branch. Вообще говоря, в подавляющем большинстве слуачаев достаточно соглашения — не коммитить ничего в tags/ каталог. Если очень хочется — можно накрутить права.
Хотя всё равно непонятно — чем так ужасен коммит в tags? Это ведь ничего не ломает, и посмотреть историю можно, и отменить можно.

J>В версиях ST, в которых не было атомарных коммитов, всё обстояло в точности так, как Вы сказали. По-моему, в нём нет ничего криминального — просто всегда нужно следить за тем, что пролезло в trunk, и всё. Benefits от этой фичи гораздо заметнее

Хотя зависит от проекта, конечно.
Старый добрый merge гораздо надёжнее.

J>>>Это в ST проще, чем в TortoiseSVN. В TortoiseSVN нужно лезть в контекстное меню, в ST достаточно открыть вкладочку history, которая будет сама обновляться, если отселектировать другой элемент (файл\каталог).
К>>Ну и что мне показывается для каталога? Я хочу видеть историю изменений файлов из этого каталога. Я её вижу в TSVN, я её не вижу в StarTeam. А как мне быстро посмотреть, что делал в январе Ваня Иванов с подкаталогом Utils?
J>Принято. Хотя для файлов в ST сделано удобнее

С наличием атомарных коммитов и истории для каталога — это, вообще говоря, не надо.
А как ST работает? Неужели он всю историю хранит локально? Почему svn так работает — понятно... А вот как так ST умудряется?

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

К>>>>>- Прозрачная работа с branch/tag
J>>>>Что значит "прозрачная работа"?
К>>>Branch, tag по сути своей являются просто каталогом в репозитории. При этом копирование внутри репозитория дешёвая операция.
К>>>Со всеми вытекающими последствиями. Очень легко понять и использовать.
J>>То, что Вы написали — это философия subVersion, и у меня в ней есть сомнения.
J>>Например, не далее как сегодня наблюдали с коллегой следующую ситуацию. Коллега выкладывал потенциально опасное изменение, и хотел перед выкладыванием поставить tag. Всё, что он хотел — всего лишь запомнить номер ревизии, до которой придётся откатить некоторые файлы, если что. SubVersion же нам предлагает в этом случае сделать branch, мотивируя это тем, что branch — операция, имеющая константную трудоёмкость. Чем плох в данной ситуации branch? Тем, что в branch кто-то может что-то закоммитить, в том числе по ошибке. В метку, tag закоммитить ничего изначально нельзя. Получается, branch после создания нужно лочить. Это всё равно не спасает от того риска, что в него что-нибудь закоммитит владелец лока (или от того, что кто-нибудь стащит лок ключиком --force). В-общем, не ясно, почему мы не можем ПРОСТО ПРИСВОИТЬ ТЕКСТОВОЕ ИМЯ НЕКОТОРОЙ РЕВИЗИИ...
.>Отличие tag и branch всего лишь в правах доступа. tag это всего лишь read only branch. Вообще говоря, в подавляющем большинстве слуачаев достаточно соглашения — не коммитить ничего в tags/ каталог. Если очень хочется — можно накрутить права.
.>Хотя всё равно непонятно — чем так ужасен коммит в tags? Это ведь ничего не ломает, и посмотреть историю можно, и отменить можно.

Соглашения — не достаточно. Потому как раз физическая возможность закоммитить в таг есть, то в силу закона Мерфи этой возможностью рано или поздно кто-нибудь воспользуется. Поэтому надо такую возможность блокировать. И потом — я же хочу ПРОСТО ПРИСВОИТЬ ТЕКСТОВОЕ ИМЯ НЕКОТОРОЙ РЕВИЗИИ. Меня заставляют создавать branch, думать о правах, а ещё говорят, что это супер-пупер какая особенность дизайна.
Зачем усложнять по сути простую задачу?

J>>В версиях ST, в которых не было атомарных коммитов, всё обстояло в точности так, как Вы сказали. По-моему, в нём нет ничего криминального — просто всегда нужно следить за тем, что пролезло в trunk, и всё. Benefits от этой фичи гораздо заметнее :-) Хотя зависит от проекта, конечно.
.>Старый добрый merge гораздо надёжнее.

Ещё раз — мой пятилетний опыт использования данной фичи показывает, что пользы неё больше, чем вреда.

J>>>>Это в ST проще, чем в TortoiseSVN. В TortoiseSVN нужно лезть в контекстное меню, в ST достаточно открыть вкладочку history, которая будет сама обновляться, если отселектировать другой элемент (файл\каталог).
К>>>Ну и что мне показывается для каталога? Я хочу видеть историю изменений файлов из этого каталога. Я её вижу в TSVN, я её не вижу в StarTeam. А как мне быстро посмотреть, что делал в январе Ваня Иванов с подкаталогом Utils?
J>>Принято. Хотя для файлов в ST сделано удобнее :)
.>С наличием атомарных коммитов и истории для каталога — это, вообще говоря, не надо.
.>А как ST работает? Неужели он всю историю хранит локально? Почему svn так работает — понятно... А вот как так ST умудряется?

Как ST умудряется что? Быстро обновлять историю?
Нет, конечно он её локально не хранит. Просто он использует ту же технологию, что через 10 лет после написания ST стали использовать в Google news — он реально запрашивает с сервера только ту часть истории, которая видна в панельке. Если начать двигать скроллер в панельке, тогда запрашивает всю, начиная с той, которую надо будет показывать в ближайшем времени.

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

— всего лишь запомнить номер ревизии, до которой придётся откатить некоторые файлы, если что. SubVersion же нам предлагает в этом случае сделать branch, мотивируя это тем, что branch — операция, имеющая константную трудоёмкость. Чем плох в данной ситуации branch? Тем, что в branch кто-то может что-то закоммитить, в том числе по ошибке. В метку, tag закоммитить ничего изначально нельзя. Получается, branch после создания нужно лочить. Это всё равно не спасает от того риска, что в него что-нибудь закоммитит владелец лока (или от того, что кто-нибудь стащит лок ключиком --force). В-общем, не ясно, почему мы не можем ПРОСТО ПРИСВОИТЬ ТЕКСТОВОЕ ИМЯ НЕКОТОРОЙ РЕВИЗИИ...
.>>Отличие tag и branch всего лишь в правах доступа. tag это всего лишь read only branch. Вообще говоря, в подавляющем большинстве слуачаев достаточно соглашения — не коммитить ничего в tags/ каталог. Если очень хочется — можно накрутить права.
.>>Хотя всё равно непонятно — чем так ужасен коммит в tags? Это ведь ничего не ломает, и посмотреть историю можно, и отменить можно.
J>Соглашения — не достаточно. Потому как раз физическая возможность закоммитить в таг есть, то в силу закона Мерфи этой возможностью рано или поздно кто-нибудь воспользуется. Поэтому надо такую возможность блокировать. И потом — я же хочу ПРОСТО ПРИСВОИТЬ ТЕКСТОВОЕ ИМЯ НЕКОТОРОЙ РЕВИЗИИ. Меня заставляют создавать branch, думать о правах, а ещё говорят, что это супер-пупер какая особенность дизайна.
Ты объясни, в чём криминал закоммитить в tag? Что может сломаться? Ну закоммитили, ну "превратили" tag в branch, ну и что? Если это было сделано по ошибке — это легко найти в истории и откатить.
А вот гораздо более нужная ситуация, когда приходится tag превращать в branch (пофиксить небольшой баг или сделать спец-билд для кого-нибдуь) как быть с "настоящим" тагом? В бытность использования cvs у меня такие проблемы возникали. А в ST эти операции константной сложности?

J>Зачем усложнять по сути простую задачу?
Так наоборот упростили. Вместо 2-х сущностей — одна.

J>>>В версиях ST, в которых не было атомарных коммитов, всё обстояло в точности так, как Вы сказали. По-моему, в нём нет ничего криминального — просто всегда нужно следить за тем, что пролезло в trunk, и всё. Benefits от этой фичи гораздо заметнее

Хотя зависит от проекта, конечно.
.>>Старый добрый merge гораздо надёжнее.
J>Ещё раз — мой пятилетний опыт использования данной фичи показывает, что пользы неё больше, чем вреда.
Да. У меня с этой фичей опыта нет. Может ты прав.

J>Как ST умудряется что? Быстро обновлять историю?
J>Нет, конечно он её локально не хранит. Просто он использует ту же технологию, что через 10 лет после написания ST стали использовать в Google news — он реально запрашивает с сервера только ту часть истории, которая видна в панельке. Если начать двигать скроллер в панельке, тогда запрашивает всю, начиная с той, которую надо будет показывать в ближайшем времени.
Понятно, коннект открытый держит значит.

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

.>Ты объясни, в чём криминал закоммитить в tag? Что может сломаться? Ну закоммитили, ну "превратили" tag в branch, ну и что? Если это было сделано по ошибке — это легко найти в истории и откатить.

Я уже объяснил. Use case следующий — я хочу присвоить текстовое имя некоторой ревизии, некоторому состоянию проекта.
Криминал в том, что мне в комплекте с этой простой вещью предлагают думать о локах, правах, откате по ошибке закоммиченных изменений, и т.п.

.>А вот гораздо более нужная ситуация, когда приходится tag превращать в branch (пофиксить небольшой баг или сделать спец-билд для кого-нибдуь) как быть с "настоящим" тагом? В бытность использования cvs у меня такие проблемы возникали. А в ST эти операции константной сложности?

Не могу сказать :-)
Если случай таков, что хочется не поименовать конкретную ревизию, а создать потенциальный Branch, то тогда нужно, конечно, создавать branch.

J>>Зачем усложнять по сути простую задачу?
.>Так наоборот упростили. Вместо 2-х сущностей — одна.

Я писал в предыдущем сообщении, в чём именно я вижу усложнение.

J>>Как ST умудряется что? Быстро обновлять историю?
J>>Нет, конечно он её локально не хранит. Просто он использует ту же технологию, что через 10 лет после написания ST стали использовать в Google news — он реально запрашивает с сервера только ту часть истории, которая видна в панельке. Если начать двигать скроллер в панельке, тогда запрашивает всю, начиная с той, которую надо будет показывать в ближайшем времени.
.>Понятно, коннект открытый держит значит.

Угу. И обижается, если модем рассоединился :-)

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

.>>Ты объясни, в чём криминал закоммитить в tag? Что может сломаться? Ну закоммитили, ну "превратили" tag в branch, ну и что? Если это было сделано по ошибке — это легко найти в истории и откатить.
J>Я уже объяснил. Use case следующий — я хочу присвоить текстовое имя некоторой ревизии, некоторому состоянию проекта.
J>Криминал в том, что мне в комплекте с этой простой вещью предлагают думать о локах, правах, откате по ошибке закоммиченных изменений, и т.п.
Ключевое слово "предлагают", а не заставляют. Тут ведь как: можешь думать об этом, а можешь и нет! И ничего страшного не случится — ничего не сломается, не потеряется.
А вот решать, что делать — бранч или таг — заставляют, ты должен делать этот выбор.

.>>А вот гораздо более нужная ситуация, когда приходится tag превращать в branch (пофиксить небольшой баг или сделать спец-билд для кого-нибдуь) как быть с "настоящим" тагом? В бытность использования cvs у меня такие проблемы возникали. А в ST эти операции константной сложности?
J>Не могу сказать

Ну в смысле создать tag/branch для каталога с 5 файлами и с 5000 файлами — одинаковая по длительности операция? В cvs — время значительно отличается, в svn — время одно, пара секунд. Как в ST?

J>Если случай таков, что хочется не поименовать конкретную ревизию, а создать потенциальный Branch, то тогда нужно, конечно, создавать branch.
А чем мерять потенцию бранча? Вот только сегодня мне понадобилось слегка пофиксить отбранченную версию, о которой я не думал, что придётся фиксить.

J>>>Зачем усложнять по сути простую задачу?
.>>Так наоборот упростили. Вместо 2-х сущностей — одна.
J>Я писал в предыдущем сообщении, в чём именно я вижу усложнение.
Это усложнение не существует объективно, а это ты усложняешь в своём субъективном восприятии. The Matrix has you.

J>>>Как ST умудряется что? Быстро обновлять историю?
J>>>Нет, конечно он её локально не хранит. Просто он использует ту же технологию, что через 10 лет после написания ST стали использовать в Google news — он реально запрашивает с сервера только ту часть истории, которая видна в панельке. Если начать двигать скроллер в панельке, тогда запрашивает всю, начиная с той, которую надо будет показывать в ближайшем времени.
.>>Понятно, коннект открытый держит значит.
J>Угу. И обижается, если модем рассоединился

Фи

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

.>Ключевое слово "предлагают", а не заставляют. Тут ведь как: можешь думать об этом, а можешь и нет! И ничего страшного не случится — ничего не сломается, не потеряется.

Хорошо, я скажу "заставляют".
Сломается. Я писал ранее.

.>А вот решать, что делать — бранч или таг — заставляют, ты должен делать этот выбор.

Наличие выбора лучше, чем его отсутствие.

J>>Если случай таков, что хочется не поименовать конкретную ревизию, а создать потенциальный Branch, то тогда нужно, конечно, создавать branch.
.>А чем мерять потенцию бранча? Вот только сегодня мне понадобилось слегка пофиксить отбранченную версию, о которой я не думал, что придётся фиксить.

Думалкой. Таг — это просто присвоение текстового имени некоторому номеру ревизии. Бранч — это бранч. Это нужно иметь в виду.

J>>>>Зачем усложнять по сути простую задачу?
.>>>Так наоборот упростили. Вместо 2-х сущностей — одна.
J>>Я писал в предыдущем сообщении, в чём именно я вижу усложнение.
.>Это усложнение не существует объективно, а это ты усложняешь в своём субъективном восприятии. The Matrix has you. :))

Каждый из нас субъективен. По сему поводу предлагаю прекратить тебе считать себя единственным источником объективности.

J>>Угу. И обижается, если модем рассоединился :-)
.>Фи :no:

С другой стороны, многие ли сейчас сидят на модеме?..

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

.>>Ключевое слово "предлагают", а не заставляют. Тут ведь как: можешь думать об этом, а можешь и нет! И ничего страшного не случится — ничего не сломается, не потеряется.
J>Хорошо, я скажу "заставляют".
J>Сломается. Я писал ранее.
Под сломается я понимаю то, что вдруг файлы станут в несогласованном состоянии.
Вот, например, плавающие ревизии могут сломать бранч. А коммит изменений в "таг" — сломать ничего не может.

.>>А вот решать, что делать — бранч или таг — заставляют, ты должен делать этот выбор.
J>Наличие выбора лучше, чем его отсутствие.
Ну если так хочется, можешь выбирать куда копировать MyProject/trunk/ — в MyProject/tags/ или в MyProject/branches/.

J>>>Если случай таков, что хочется не поименовать конкретную ревизию, а создать потенциальный Branch, то тогда нужно, конечно, создавать branch.
.>>А чем мерять потенцию бранча? Вот только сегодня мне понадобилось слегка пофиксить отбранченную версию, о которой я не думал, что придётся фиксить.
J>Думалкой. Таг — это просто присвоение текстового имени некоторому номеру ревизии. Бранч — это бранч. Это нужно иметь в виду.
Вчерашняя ситуация — делаю версию v1.02.03. Сделал копию в tags/, начал собирать setup.exe и вдруг чувак за соседним столом просит: "обновись плз, только что поправил опечатку в тексте". Ну я прервал процесс, проапдейтился и собрал setup.exe. Потом замерджил его изменения в tags/v1.02.03. Думалка думалкой, а вот телепатия не работает.

J>>>>>Зачем усложнять по сути простую задачу?
.>>>>Так наоборот упростили. Вместо 2-х сущностей — одна.
J>>>Я писал в предыдущем сообщении, в чём именно я вижу усложнение.
.>>Это усложнение не существует объективно, а это ты усложняешь в своём субъективном восприятии. The Matrix has you.

J>Каждый из нас субъективен. По сему поводу предлагаю прекратить тебе считать себя единственным источником объективности.
Неа. Вот, например, мнение о том, что таг надёжнее бранча в том плане, что его нельзя изменить — иллюзорно. Мол, бранч если даже залочить, но мол украть лок могут с --force и прочие страхи.
А ведь с тагами ситуация та же — если захотят — изменят. Можно просто удалить таг и создать с тем же именем. Не знаю как в ST, но в cvs об этом даже запись в истории не оставалась, афаир.

J>>>Угу. И обижается, если модем рассоединился

.>>Фи

J>С другой стороны, многие ли сейчас сидят на модеме?..
Бывает нередко (по крайней мере не реже, чем мне понадобилось посмотреть больше 100 записей в логе), что российские сети колбасит нехило...

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

.>Под сломается я понимаю то, что вдруг файлы станут в несогласованном состоянии.
.>Вот, например, плавающие ревизии могут сломать бранч. А коммит изменений в "таг" — сломать ничего не может.

Может. Я хотел, чтобы таг "My favourite version" маркировал ревизию 123456, а туда кто-то закоммитился, и он теперь маркирует ревизию 123457.

.>>>А вот решать, что делать — бранч или таг — заставляют, ты должен делать этот выбор.
J>>Наличие выбора лучше, чем его отсутствие.
.>Ну если так хочется, можешь выбирать куда копировать MyProject/trunk/ — в MyProject/tags/ или в MyProject/branches/.

Это неинтересный выбор, функционально от него ничего не зависит.

.>Вчерашняя ситуация — делаю версию v1.02.03. Сделал копию в tags/, начал собирать setup.exe и вдруг чувак за соседним столом просит: "обновись плз, только что поправил опечатку в тексте". Ну я прервал процесс, проапдейтился и собрал setup.exe. Потом замерджил его изменения в tags/v1.02.03. Думалка думалкой, а вот телепатия не работает.

В данном use case следовало делать бранч.

.>А ведь с тагами ситуация та же — если захотят — изменят. Можно просто удалить таг и создать с тем же именем. Не знаю как в ST, но в cvs об этом даже запись в истории не оставалась, афаир.

Это проблемы CVS. Не должно быть возможности менять/пересоздавать таг.

.>Бывает нередко (по крайней мере не реже, чем мне понадобилось посмотреть больше 100 записей в логе), что российские сети колбасит нехило...
Никогда от этого не страдал... Тогда TFS извне тебе вообще противопоказан — он если сеть отваливается, затыкает студию не по-детски...

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

.>>Под сломается я понимаю то, что вдруг файлы станут в несогласованном состоянии.
.>>Вот, например, плавающие ревизии могут сломать бранч. А коммит изменений в "таг" — сломать ничего не может.
J>Может. Я хотел, чтобы таг "My favourite version" маркировал ревизию 123456, а туда кто-то закоммитился, и он теперь маркирует ревизию 123457.
И что? В чём именно жизненная необходимость такого ограничения? Пока я вижу только одно: "Я так хочу!".

.>>>>А вот решать, что делать — бранч или таг — заставляют, ты должен делать этот выбор.
J>>>Наличие выбора лучше, чем его отсутствие.
.>>Ну если так хочется, можешь выбирать куда копировать MyProject/trunk/ — в MyProject/tags/ или в MyProject/branches/.
J>Это неинтересный выбор, функционально от него ничего не зависит.
А выбор между тагом и бранчем обычно должен быть в пользу бранча. Так что тоже неинтересный выбор.

.>>Вчерашняя ситуация — делаю версию v1.02.03. Сделал копию в tags/, начал собирать setup.exe и вдруг чувак за соседним столом просит: "обновись плз, только что поправил опечатку в тексте". Ну я прервал процесс, проапдейтился и собрал setup.exe. Потом замерджил его изменения в tags/v1.02.03. Думалка думалкой, а вот телепатия не работает.
J>В данном use case следовало делать бранч.
Почему? Ведь до этого я собирал 100 версий, создавая таг, и до этого меня не прерывали на пол пути, и изменять таг не приходилось, а вот тут вдруг понадобилось. Т.е. потенциально любой таг может превратиться в бранч, а значит таги использовать не следует.

.>>А ведь с тагами ситуация та же — если захотят — изменят. Можно просто удалить таг и создать с тем же именем. Не знаю как в ST, но в cvs об этом даже запись в истории не оставалась, афаир.
J>Это проблемы CVS. Не должно быть возможности менять/пересоздавать таг.
Бред. А если я опечатался? Случайно не ту кнопку нажал?

.>>Бывает нередко (по крайней мере не реже, чем мне понадобилось посмотреть больше 100 записей в логе), что российские сети колбасит нехило...
J>Никогда от этого не страдал... Тогда TFS извне тебе вообще противопоказан — он если сеть отваливается, затыкает студию не по-детски...
Ага, ещё один плюс svn.

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

.>И что? В чём именно жизненная необходимость такого ограничения? Пока я вижу только одно: "Я так хочу!".

Да. Я так хочу.
Я хочу, чтобы у меня была возможность присвоить некоторой ревизии текстовое имя.
Всё.

.>>>Вчерашняя ситуация — делаю версию v1.02.03. Сделал копию в tags/, начал собирать setup.exe и вдруг чувак за соседним столом просит: "обновись плз, только что поправил опечатку в тексте". Ну я прервал процесс, проапдейтился и собрал setup.exe. Потом замерджил его изменения в tags/v1.02.03. Думалка думалкой, а вот телепатия не работает.
J>>В данном use case следовало делать бранч.
.>Почему? Ведь до этого я собирал 100 версий, создавая таг, и до этого меня не прерывали на пол пути, и изменять таг не приходилось, а вот тут вдруг понадобилось. Т.е. потенциально любой таг может превратиться в бранч, а значит таги использовать не следует.

Ещё раз.
Если ты создаёшь какую-то там версию, то для этого придумали бранч.
Таг нужен тогда и только тогда, когда тебе нужно просто запомнить как-то, помаркировать текстовой меткой номер некоторой ревизии.

.>>>А ведь с тагами ситуация та же — если захотят — изменят. Можно просто удалить таг и создать с тем же именем. Не знаю как в ST, но в cvs об этом даже запись в истории не оставалась, афаир.
J>>Это проблемы CVS. Не должно быть возможности менять/пересоздавать таг.
.>Бред. А если я опечатался? Случайно не ту кнопку нажал?

А если ты опечатался в имени бранча?
Или вместо команды regedit случайно напечатал format c: ?
Твои проблемы, я полагаю.

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

.>>>>Вчерашняя ситуация — делаю версию v1.02.03. Сделал копию в tags/, начал собирать setup.exe и вдруг чувак за соседним столом просит: "обновись плз, только что поправил опечатку в тексте". Ну я прервал процесс, проапдейтился и собрал setup.exe. Потом замерджил его изменения в tags/v1.02.03. Думалка думалкой, а вот телепатия не работает.
J>>>В данном use case следовало делать бранч.
.>>Почему? Ведь до этого я собирал 100 версий, создавая таг, и до этого меня не прерывали на пол пути, и изменять таг не приходилось, а вот тут вдруг понадобилось. Т.е. потенциально любой таг может превратиться в бранч, а значит таги использовать не следует.
J>Ещё раз.
J>Если ты создаёшь какую-то там версию, то для этого придумали бранч.
J>Таг нужен тогда и только тогда, когда тебе нужно просто запомнить как-то, помаркировать текстовой меткой номер некоторой ревизии.
А для чего такое может понадобится? В какой ситуации это необходимо и бранч недопустим?

.>>>>А ведь с тагами ситуация та же — если захотят — изменят. Можно просто удалить таг и создать с тем же именем. Не знаю как в ST, но в cvs об этом даже запись в истории не оставалась, афаир.
J>>>Это проблемы CVS. Не должно быть возможности менять/пересоздавать таг.
.>>Бред. А если я опечатался? Случайно не ту кнопку нажал?
J>А если ты опечатался в имени бранча?
Переименую.

J>Или вместо команды regedit случайно напечатал format c: ?
Это слишком разные вещи, так опечататься невозможно. К тому же, "format c:" не работает просто так. Он тебе задаст кучу вопросов: "а ты уверен?". К тому же, под XP ты не сможешь отформатировать системный диск, даже если очень захочешь.

J>Твои проблемы, я полагаю.
Хорошая программная система предотвращает ошибки пользователей. Люди ошыбаються, это такое неотъемлимое свойство человеков. Обязанность хорошей программы — стремиться исключить возможность ошибок или позволить легко их исправлять.

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

Позвольте вопрос. Я так понял, что вы используете ST в своей работе. Приходилось ли использовать плагин ST для VS 2005? И есть ли вообще хоть один приличный плагин для VS , а не то глюкалово, которое производит борланд.

Здравствуйте, Щербатов Евгений, Вы писали:

ЩЕ>Позвольте вопрос. Я так понял, что вы используете ST в своей работе. Приходилось ли использовать плагин ST для VS 2005? И есть ли вообще хоть один приличный плагин для VS , а не то глюкалово, которое производит борланд.

Использовал год назад.
Честно говоря, никогда не пользовался ST'овской интеграцией со студией.
Более того — считаю, что раз есть хороший толстый клиент, то и интеграция со студией не шибко нужна...

Здравствуйте, Jiojju:
У меня есть вопросики по MS Team Foundation, его настройке и использованию:
1. Есть ли какая нибудь дока на русском по установке и начале работы (пока хотелось бы начать только с контроля версий).
2. Говорят что TFS достаточно не прост в установке, так ли это?

А>У меня есть вопросики по MS Team Foundation, его настройке и использованию:
А>1. Есть ли какая нибудь дока на русском по установке и начале работы (пока хотелось бы начать только с контроля версий).
В английской всё доходчиво расписано
А>2. Говорят что TFS достаточно не прост в установке, так ли это?
По инструкции ставится без проблем. Всё описано — необходимость 3х (доменных) учеток при инсталляции, SQL Server

... << RSDN@Home 1.2.0 alpha rev. 648>>

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

.>>И что? В чём именно жизненная необходимость такого ограничения? Пока я вижу только одно: "Я так хочу!".
J>Да. Я так хочу.
J>Я хочу, чтобы у меня была возможность присвоить некоторой ревизии текстовое имя.
J>Всё.
Ок. Без проблем — вешаем на репозиторий commit-скрипт, который будет проверять не пытаешься ли ты закоммитить в каталог с тэгом. Если пытаешься — будет откатывать коммит. Естественно, сервеные commit-скрипты — это стандартная функциональность.

В SVN даже в документаии вроде где-то этот скриптик был.

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

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

bnk>>IMHO, это просто смешно.
bnk>>Лично мне "в плане usability" Tortoise представляется ОЧЕНЬ удачной.

J>Значит, следует признать, что по этому вопросу бывают разные мнения

J>Для интереса — Вы со StarTeam работали сколь-нибудь существенное время?

Я пользовался. В 2001 — 2002. Оно еще живо? Удивлен. И что?

J>Принято. Хотя тот факт, что данная фича совершенно undiscoverable (интересно, какое отношение глагол "Обвинять" имеет к тому, что делает данная фича?) — недоработка черепашки

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

J>Как я понимаю, речь идёт о том, чтобы на каталоге мышой выбрать пункт меню "Add"?
J>Принято.

Вообще, существует определенная дисциплина использования vcs, потому что это такой же инструмент разработки как компилятор или make. Крайне простая и незатейливая. svn up, svn status, svn commit. При таком подходе что-то забыть положить в контроль версий крайне трудно.

bnk>>Это просто неправда.
bnk>>Пунктик меню "Check for modifications", кнопочка "Check repository" делает ровно это —
bnk>>выводит список файлов, которые изменились по сравнению с рабочей копией.

J>Просто ужасающе non-discoverable.

вообще, я смотрю что гуй для вершен контролей это просто жуть.
Какие-то многоэтажные названия вместо автоматического svn status перед коммитом...

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

C>Ок. Без проблем — вешаем на репозиторий commit-скрипт, который будет проверять не пытаешься ли ты закоммитить в каталог с тэгом. Если пытаешься — будет откатывать коммит. Естественно, сервеные commit-скрипты — это стандартная функциональность.

C>В SVN даже в документаии вроде где-то этот скриптик был.

все еще проще

я как раз недавно такую вещь правил, так что это как 2 байта переслать. В венде просто создать exe в папке hooks.
Единственная фигня с svn в том что есть ситуации когда при создании тега на один и тот же элемент приходит 2 уведомления в changeset'е (1 remove и 1 add

) поэтому примитивная логика которая проверяет что тэги не меняют иногда дает ложные срабатывания.

best regards

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

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

V>>Что лучше SVN или MS Team Foundation ?

bnk>Честно говоря не уверен что TFS вообще кто-то использует...
bnk>Если хоть кто-то его реально использует, мне тоже было бы интересно услышать отзывы.

Мы юзаем активно TFS! А почему вы думаете, что никто не будет его использовать? Для построения рабочего процесса очень даже ничего, хотя конечно, маловато возможностей в плане контроля тасков и фикса багов... Хочется большей конкретики

У SVN под винду есть проблемы

1. очень неудобно, что SVN под винду различает регистр имён файлов. Случалось такое, что один человек добавил файл resource.h а другой — Resource.h SVN позволяет так сделать, но потом Update облмывается

2. Иногда возникает ситуация, что папка оказывается заблокированной, и clear up не помогает. Приходится копировать всё в темп, грохать, делать апдейт, потом сверху заливать

3. Неудобно, что локлаьная информация хранится в папках .svn. Если надо, например, подготовить архив с исходниками, то надо все исходники куда-ниьудь скопировать, там эти папки грохнуть, потом запаковать. У Perforce, например, такого нет

4. Есть проблемы с совместимость версий. А версий бывает много разных. Например, если один репозиторий нахожится под сервером 1.3, а второй — 1.4, а черепашку-то надо только одну версию ставить!

5. Интеграция с VS. Пробовал ArckSVN, кажется. Глючило ужас.

а в Linux и Mac OS X — это разные символы...
нас спасает naming convention

ЕК>2. Иногда возникает ситуация, что папка оказывается заблокированной, и clear up не помогает. Приходится копировать всё в темп, грохать, делать апдейт, потом сверху заливать

ЕК>3. Неудобно, что локлаьная информация хранится в папках .svn. Если надо, например, подготовить архив с исходниками, то надо все исходники куда-ниьудь скопировать, там эти папки грохнуть, потом запаковать. У Perforce, например, такого нет

svn export или в черепашке есть соответствующий пункт меню...

ЕК>4. Есть проблемы с совместимость версий. А версий бывает много разных. Например, если один репозиторий нахожится под сервером 1.3, а второй — 1.4, а черепашку-то надо только одну версию ставить!

Да... это тяжелый случай... у нас все сервера up-to-date...

ЕК>5. Интеграция с VS. Пробовал ArckSVN, кажется. Глючило ужас.

Хм... Это уже флеймовая тема... Скорее о том как вести проект чем как его синхронизировать

Потому как у меня src (где исходники кроссплатформенного проекта с солюшенами кутишными .pro — файлами в том числе) — это всего лишь часть проекта...
Есть ещё Documentation, Forms, Thirdparty, Docs, Tools ... — их тоже со студии манажить?

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

J>А можно поподробнее?
J>Что именно Вас не устраивает в ST, что устраивало в TortoiseSVN?

Давно хотел именно вам задать вопрос по StarTeam — такое ощущение, что на данном форуме вы в нем самый дока. Я считаю, что StarTeam одна из наиболее удобных систем, которую мне приходилось использовать, но есть одна особенность, которая на нет сводит все его достоинства. StarTeam у нас очень плохо показывает обновления, сделанные в репозитории. Т.е. предположим один пользователь добавил/изменил/удалил файл в хранилище, другой по F5 должен это увидеть. Так вот F5 эти файлы то показывает, то не показывает — не могу понять от чего это зависит. Люди уже взяли себе за привычку закрывать клиента и переоткрывать его снова, чтобы гарантировано видеть, что их локальный репозиторий в точности синхронизирован с тем, который на сервере. А изменений в Change Requests мы вообще никогда не видим — все время клиента переоткрывать приходится.

У меня есть подозрение, что клиент StarTeam каким-то образом теряет связь с сервером обновлений. У нас ребята свои рабочие программы не перегружают неделями (MS VS например). А со StarTeam подобные косяки с обновлением начинают проявляться вроде как раз после того, как какой-либо проект в нем открыт достаточно долго. Может быть топология нашей сети как-то влияет? Прямо так обидно... — все у него ништяк и АПИ мощный (мы на нем автоматизировали свои билды) и вообще, а обновление не работает.

Здравствуйте, Евгений Коробко, Вы писали:

ЕК>У SVN под винду есть проблемы

ЕК>1. очень неудобно, что SVN под винду различает регистр имён файлов. Случалось такое, что один человек добавил файл resource.h а другой — Resource.h SVN позволяет так сделать, но потом Update облмывается

Действительно, неудобно, особенно если учесть, что VS 2005 лбит менять case в именах файлов. Но, в принципе, после установки хука, не дающего выкладывать такое, проблем больше не возникает

ЕК>2. Иногда возникает ситуация, что папка оказывается заблокированной, и clear up не помогает. Приходится копировать всё в темп, грохать, делать апдейт, потом сверху заливать

Никогда не сталкивался — Clean Up всегда помогал

ЕК>3. Неудобно, что локлаьная информация хранится в папках .svn. Если надо, например, подготовить архив с исходниками, то надо все исходники куда-ниьудь скопировать, там эти папки грохнуть, потом запаковать. У Perforce, например, такого нет

У RARб например, есть соответствующие ключики. А на крайний случай — svn export

ЕК>4. Есть проблемы с совместимость версий. А версий бывает много разных. Например, если один репозиторий нахожится под сервером 1.3, а второй — 1.4, а черепашку-то надо только одну версию ставить!

С этим могу сказать только одно — у нас сервер 1.2, а клиенты — 1.4. Все прекрасно работает. С равным успехом работала связка сервер 1.2 — клиент 1.3

Алексей Мартынов

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Алексей Мартынов, Вы писали:

АМ>Здравствуйте, Евгений Коробко, Вы писали:

ЕК>>У SVN под винду есть проблемы

ЕК>>1. очень неудобно, что SVN под винду различает регистр имён файлов. Случалось такое, что один человек добавил файл resource.h а другой — Resource.h SVN позволяет так сделать, но потом Update облмывается

АМ>Действительно, неудобно, особенно если учесть, что VS 2005 лбит менять case в именах файлов. Но, в принципе, после установки хука, не дающего выкладывать такое, проблем больше не возникает

хук не пропускает заглавные буквы?

мы просто пользуемся своими визардами... там как назовешь класс — точно так же и файл будет. тоесть знаешь наверняка если MyClass — то получится MyClass.h + MyClass.cpp
и все обязаны пользоваться именно этими визардами...

вообще... крайне редко получается такая ситуация что может получиться ещё 1 файл аля myClass.cpp или что то в этом роде — конфликтующее... и отрезолвить это вполне реально

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

ЕК>>>1. очень неудобно, что SVN под винду различает регистр имён файлов. Случалось такое, что один человек добавил файл resource.h а другой — Resource.h SVN позволяет так сделать, но потом Update облмывается

АМ>>Действительно, неудобно, особенно если учесть, что VS 2005 лбит менять case в именах файлов. Но, в принципе, после установки хука, не дающего выкладывать такое, проблем больше не возникает

DV>хук не пропускает заглавные буквы?

Нет, он не дает выложить файл с именем, которое отличается от уже имеющегося только регистром букв.

Алексей Мартынов

PS. Ты бы видел, как я прыгал первый раз вокруг Darcs'а после того, как VS 2005 переименовала мне Resource.h -> resource.h

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

DV>Да — это проблемма... согласен..
DV>Предложите способ решения...
В windows версии, в коде, который проверяет наличие файла в реполитории, юзать stricmp вместо strcmp. Одна строка по идее.

DV>Да... это тяжелый случай... у нас все сервера up-to-date...

Бывает, что у клиента свой SVN сервер и он хочет, чтобы мы работали с ним.

Здравствуйте, Алексей Мартынов, Вы писали:

АМ>Здравствуйте, Dj.ValDen, Вы писали:

ЕК>>>>1. очень неудобно, что SVN под винду различает регистр имён файлов. Случалось такое, что один человек добавил файл resource.h а другой — Resource.h SVN позволяет так сделать, но потом Update облмывается

АМ>>>Действительно, неудобно, особенно если учесть, что VS 2005 лбит менять case в именах файлов. Но, в принципе, после установки хука, не дающего выкладывать такое, проблем больше не возникает

DV>>хук не пропускает заглавные буквы?

АМ>Нет, он не дает выложить файл с именем, которое отличается от уже имеющегося только регистром букв.

А можете поделиться этим куком?

Здравствуйте, Евгений Коробко, Вы писали:

DV>>Да — это проблемма... согласен..
DV>>Предложите способ решения...
ЕК>В windows версии, в коде, который проверяет наличие файла в реполитории, юзать stricmp вместо strcmp. Одна строка по идее.

вот только работаь нормально будет только для латиницы

DV>>Да... это тяжелый случай... у нас все сервера up-to-date...

ЕК>Бывает, что у клиента свой SVN сервер и он хочет, чтобы мы работали с ним.

Здравствуйте, Щербатов Евгений, Вы писали:

ЩЕ>Позвольте вопрос. Я так понял, что вы используете ST в своей работе. Приходилось ли использовать плагин ST для VS 2005? И есть ли вообще хоть один приличный плагин для VS , а не то глюкалово, которое производит борланд.

Я использовал (никаких проблем), но это было давно. А что с ним сейчас не так?

... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>

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

AF>Здравствуйте, Щербатов Евгений, Вы писали:

ЩЕ>>Позвольте вопрос. Я так понял, что вы используете ST в своей работе. Приходилось ли использовать плагин ST для VS 2005? И есть ли вообще хоть один приличный плагин для VS , а не то глюкалово, которое производит борланд.

AF>Я использовал (никаких проблем), но это было давно. А что с ним сейчас не так?

А вы попробуйте поработать с ним, когда в solution VS не один, а несколько проектов, например.

Здравствуйте, Щербатов Евгений, Вы писали:

ЩЕ>А вы попробуйте поработать с ним, когда в solution VS не один, а несколько проектов, например.

Работал

Может, сломали чего-нибудь со временем? В общем, расскажите, интересно

... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>

Здравствуйте, Евгений Коробко, Вы писали:

ЕК>4. Есть проблемы с совместимость версий. А версий бывает много разных. Например, если один репозиторий нахожится под сервером 1.3, а второй — 1.4, а черепашку-то надо только одну версию ставить!

Информация не соответствует действительности, если вы не используете ранние альфы типа svn-0.27.0 в качестве сервера.

DV>>Да — это проблемма... согласен..
DV>>Предложите способ решения...
ЕК>В windows версии, в коде, который проверяет наличие файла в реполитории, юзать stricmp вместо strcmp. Одна строка по идее.

DV>>Да... это тяжелый случай... у нас все сервера up-to-date...

ЕК>Бывает, что у клиента свой SVN сервер и он хочет, чтобы мы работали с ним.

Поставьте себе последний клиентский пакет и работайте с любыми серверами. Под "любыми" понимается версия 1.0 (полное старьё на текущий момент) и выше.

См. http://svn.collab.net/repos/svn/trunk/subversion/libsvn_ra_svn/protocol , пункт 2.1 "Capabilities".

Здравствуйте, Константин Л., Вы писали:

DV>>>Да — это проблемма... согласен..
DV>>>Предложите способ решения...
ЕК>>В windows версии, в коде, который проверяет наличие файла в реполитории, юзать stricmp вместо strcmp. Одна строка по идее.

КЛ>вот только работаь нормально будет только для латиницы

Вообще не будет работать нормально.
Евгений Коробко почему-то не может представить ситуацию, когда сервер на винде, а клиенты — юниксы. А люди все разные, и ситуации тоже разные.

Здравствуйте, Константин Л., Вы писали:

ЕК>>В windows версии, в коде, который проверяет наличие файла в реполитории, юзать stricmp вместо strcmp. Одна строка по идее.
КЛ>вот только работаь нормально будет только для латиницы
Для всего. Там должна, по идее, использоваться locale-aware версия. По крайней мере, там уже были ошибки из-за излишней локальности (с турецкой i-dotless).

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

АМ>>Нет, он не дает выложить файл с именем, которое отличается от уже имеющегося только регистром букв.

DV>А можете поделиться этим куком?

http://subversion.tigris.org/tools_contrib.html#case_insensitive_py

_FR>Если бы использовали только source code control, то поменяли бы на свн или нет и почему?

SVN проблемно к домену прикрутить

_FR>Нет ли проблем, как с VSS при работе нескольких десятков человек, расположенных далеко друг от друга?

Работал по VPN через ADSL, всё отлично

Здравствуйте, Евгений Коробко, Вы писали:

_FR>>Если бы использовали только source code control, то поменяли бы на свн или нет и почему?

ЕК>SVN проблемно к домену прикрутить

И в чём же "проблемы"? Прочесть три абзаца документации?

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

ЕК>>SVN проблемно к домену прикрутить

D>И в чём же "проблемы"? Прочесть три абзаца документации?

Речь об использовании доменных пользователей? Если да, то можно и документацию не читать, а просто поставить VisualSvnServer

Mumitroler

... << RSDN@Home 1.2.0 alpha 4 rev. 1099>>

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

bnk>>Ну чем например плох Tortoise?

J>В первую очередь, своими бедными характеристиками в плане usability. Навкидку, вспоминаются следующие use-case:

Ни один из четырех пунктов не соответствует действительности. В том смысле, что если быть ну очень невнимательным и предвзятым, то о проблемы эти споткнуться можно, особенно если заранее отказаться подумать, что есть этим проблемам очевидное решение.

J>В-общем, перечислять можно долго.

Написали бы сразу "субъективно не нравится" и даже первые пункты не надо было бы перечислять.

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

J>Соглашения — не достаточно. Потому как раз физическая возможность закоммитить в таг есть, то в силу закона Мерфи этой возможностью рано или поздно кто-нибудь воспользуется. Поэтому надо такую возможность блокировать.

Сомнительная аргументация. Безотносительно от. Кто-то из корифеев юзабилити рассказывал такую историю — в кассовых аппаратах не было возможности отменить операцию, если уже введена сумма. Так вот, кассиры просто ребутили кассовый аппарат, что приводило к гораздо большим проблемам.
Учитесь, в общем, доверять тем, с кем рядом работаете.

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

V>Что лучше SVN или MS Team Foundation ?

Обращусь к сообществу с таким вопросом по теме. При работе через VPN с VSS на буржуинском сервере имеют место быть дикие тормоза. Это насколько помню объясняется особенностями протокола, который суть медленный в сетях с длинными пингами.
Так вот.
1. Решили ли проблему в TFS?
2. Существует ли такая проблема в StarTeam?

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

SE>Обращусь к сообществу с таким вопросом по теме. При работе через VPN с VSS на буржуинском сервере имеют место быть дикие тормоза. Это насколько помню объясняется особенностями протокола, который суть медленный в сетях с длинными пингами.

SE>1. Решили ли проблему в TFS?
Работаю через VPN с TFS на буржуинском сервере. Тормозов не замечено.

... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>

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

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

V>>Что лучше SVN или MS Team Foundation ?

SE>Обращусь к сообществу с таким вопросом по теме. При работе через VPN с VSS на буржуинском сервере имеют место быть дикие тормоза. Это насколько помню объясняется особенностями протокола, который суть медленный в сетях с длинными пингами.
Да нету особенно никаких протоколов, просто VSS работает через файловую систему. Тормозит не подетски, согласен.

SE>Так вот.
SE>1. Решили ли проблему в TFS?
TFS совсем по другому работает. Тут есть сервер. Но как уже говорили нужен практически постоянный коннект с сервером

SE>2. Существует ли такая проблема в StarTeam?
Проблема StarTeam — это то что он до сих пор существует. Давно такого г.. не видел, а вот на те, приходится скрипя зубами работать.
Нет особо не тормозит, но вот сотни мегабайт за день приходится переганять дабы эта поделка наконец то синхронизировала громадный проэкт. В день тратится около часа на борьбу с "фичами".

Не парьте себе моск этими монстрами. Поставьте SVN

	От:	vgrigor
	Дата:	09.04.07 15:27
	Оценка:

От:	bnk	http://unmanagedvisio.com/
Дата:	09.04.07 15:49
Оценка:

	От:	Lloyd
	Дата:	09.04.07 15:49
	Оценка:

	От:	Lloyd
	Дата:	09.04.07 15:50
	Оценка:

	От:	vgrigor
	Дата:	09.04.07 15:54
	Оценка:

От:	Сергей Туленцев	http://software.tulentsev.com
Дата:	09.04.07 19:31
Оценка:

От:	_FRED_	@ViIvanov
Дата:	11.04.07 14:11
Оценка:

	От:	Константин
	Дата:	18.04.07 14:10
	Оценка:	1 (1) -1

	От:	Щербатов Евгений
	Дата:	02.05.07 07:09
	Оценка:

	От:	Евгений Коробко
	Дата:	17.09.07 12:22
	Оценка:

От:	Dj.ValDen	http://ua.linkedin.com/in/dvalchuk
Дата:	17.09.07 14:26
Оценка:

	От:	Алексей Мартынов
	Дата:	18.09.07 07:22
	Оценка:

	От:	Константин Л.
	Дата:	26.09.08 17:51
	Оценка:

	От:	Jiojju
	Дата:	13.04.07 15:56
	Оценка:	+1 -1

	От:	Left2
	Дата:	13.04.07 17:37
	Оценка:

	От:	gid_vvp
	Дата:	23.04.07 06:06
	Оценка:

	От:	Jiojju
	Дата:	23.04.07 06:13
	Оценка: