Здравствуйте, 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 ?

Здравствуйте, 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 достаточно не прост в установке, так ли это?