Привет!
У нас в компании есть по сути два направления: десктоп приложения и web-клиенты использующие одну и ту же БД. Сейчас используется SVN + Redmine как для десктоп приложения (это OpenEdge ABL), так и для web приложений (ASP.NET). Очень печалит поддержка SVN в студии — с ветками работать очень тяжело, фактически невозможно (используем AnkSVN). Подумываю о переносе всего и вся в TFS. Вопрос — можно ли хранить в TFS принципиально отличные от MS виды проектов?

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

M>Привет!
M>У нас в компании есть по сути два направления: десктоп приложения и web-клиенты использующие одну и ту же БД. Сейчас используется SVN + Redmine как для десктоп приложения (это OpenEdge ABL), так и для web приложений (ASP.NET). Очень печалит поддержка SVN в студии — с ветками работать очень тяжело, фактически невозможно (используем AnkSVN). Подумываю о переносе всего и вся в TFS. Вопрос — можно ли хранить в TFS принципиально отличные от MS виды проектов?

Зачем с ветками в студии работать, что под этим подразумевается? Есть же клиент родной, есть TortoiseSVN.

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

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

M>>Привет!
M>>У нас в компании есть по сути два направления: десктоп приложения и web-клиенты использующие одну и ту же БД. Сейчас используется SVN + Redmine как для десктоп приложения (это OpenEdge ABL), так и для web приложений (ASP.NET). Очень печалит поддержка SVN в студии — с ветками работать очень тяжело, фактически невозможно (используем AnkSVN). Подумываю о переносе всего и вся в TFS. Вопрос — можно ли хранить в TFS принципиально отличные от MS виды проектов?

GIV>Зачем с ветками в студии работать, что под этим подразумевается? Есть же клиент родной, есть TortoiseSVN.

Например есть задачка которую нужно делать в ветке. Создание ветки в студии с помощью AnkhSVN — это квест. Переключение между ветками не пойми как работает. Вроде переключает, а коммитишь и понимаешь что залил не туда.

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

GIV>>Зачем с ветками в студии работать, что под этим подразумевается? Есть же клиент родной, есть TortoiseSVN.

M>Например есть задачка которую нужно делать в ветке. Создание ветки в студии с помощью AnkhSVN — это квест. Переключение между ветками не пойми как работает. Вроде переключает, а коммитишь и понимаешь что залил не туда.

Понятно, я как то привык c ветками работать родными средствами. Из IDE только update/commit/add/delete ect.

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

M>печалит поддержка SVN в студии — с ветками работать очень тяжело, фактически невозможно (используем AnkSVN)

Есть мнение, что это не из-за AnkhSVN с ветками тяжело работать, а из-за самого SVN.

M>Подумываю о переносе всего и вся в TFS.

В TFS с ветками не сильно лучше.

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

M>Например есть задачка которую нужно делать в ветке. Создание ветки в студии с помощью AnkhSVN — это квест. Переключение между ветками не пойми как работает. Вроде переключает, а коммитишь и понимаешь что залил не туда.

В VisualSVN c этим вроде получше.

Здравствуйте, Нахлобуч, Вы писали:

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

M>>печалит поддержка SVN в студии — с ветками работать очень тяжело, фактически невозможно (используем AnkSVN)

Н>Есть мнение, что это не из-за AnkhSVN с ветками тяжело работать, а из-за самого SVN.

M>>Подумываю о переносе всего и вся в TFS.

Н>В TFS с ветками не сильно лучше.

Здесь мне нужно время на изучение Приятно что TFS можно взять в триал на 3 месяца. Но два из них я убил на установку ))) Я то думал что у MS все ставится "из коробки"

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

M>Здесь мне нужно время на изучение Приятно что TFS можно взять в триал на 3 месяца. Но два из них я убил на установку ))) Я то думал что у MS все ставится "из коробки"

Я несколько предвзят (см. подпись), но попробуй Mercurial (если нет противопоказаний вроде больших бинарных файлов или дизайнеров в команде).

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

M> Очень печалит поддержка SVN в студии — с ветками работать очень тяжело, фактически невозможно (используем AnkSVN). Подумываю о переносе всего и вся в TFS. Вопрос — можно ли хранить в TFS принципиально отличные от MS виды проектов?

С анком — да, лучше ограничиться commit-update. С TortoiseSVN (начиная с 1.8) создавать ветки/мержить несложно:

1. Обновляем trunk до самой свежей ревизии, убеждаемся что нет незакоммиченных изменений
2. В контекстном меню рабочей копии — Branch/tag, указываем ветку, не забываем включить swith working copy.
3. Работаем в ветке. Если нужно забрать в ветку изменения из транка — merge range of revisions, merge from — trunk, указываем нужные номера ревизий.
4. Добили ветку — убеждаемся что нет незакоммиченных изменений, делаем switch на рабочую копию. 1.8. автоматом выполняет слияние веток, поэтому снова merge range of revisions, в merge from указываем нашу ветку, выбираем пункт all revisions.

Чёрт его знает, куда проще

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

M>Привет!
M>У нас в компании есть по сути два направления: десктоп приложения и web-клиенты использующие одну и ту же БД. Сейчас используется SVN + Redmine как для десктоп приложения (это OpenEdge ABL), так и для web приложений (ASP.NET). Очень печалит поддержка SVN в студии — с ветками работать очень тяжело, фактически невозможно (используем AnkSVN). Подумываю о переносе всего и вся в TFS. Вопрос — можно ли хранить в TFS принципиально отличные от MS виды проектов?

Ответ на ваш вопрос — да это возможно и это будет работать.
Но я бы не рекомендовал вам делать этого. TFS и его tools довольно посредственная система в целом (на мой взгляд), особенно за свои деньги.
1) Если вы имеете достаточно денег, я рекомендую perforce
2) Если денег нет то отличный вариант mercurial + phabricator

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

M> Очень печалит поддержка SVN в студии — с ветками работать очень тяжело,

Если важна работа с ветками, то стоит подумать о git. Он чуть более чем успешно применяется во многих коммерческих проектах.

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

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

M>> Очень печалит поддержка SVN в студии — с ветками работать очень тяжело,

К>Если важна работа с ветками, то стоит подумать о git. Он чуть более чем успешно применяется во многих коммерческих проектах.

+1 за GIT.
2013 студия поддерживает его из коробки, 2012 — после установки расширения.

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

bnk>+1 за GIT.
bnk>2013 студия поддерживает его из коробки, 2012 — после установки расширения.

Чисто ради поддержки студии я бы не связывался. Для небольших локальных команд (до 20-30 человек) более чем удобна связка из ankhsvn+tortoise (на клиенте) и svn+trac+тимсити (на сервере).

До удобств анка (в плане работы прямо из студии — забрал тикет, поправил, закоммитил) что git, что vstfs ещё расти и расти. Увы

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

S>что vstfs ещё расти и расти
А чем в таком сценарии TFS проигрывает AnkhSVN?
Вроде все делается 1-в-1, ну может команды несколько различаются + есть особенности, к которым нужно привыкнуть после SVN (например, та же разница в терминологии: Cheсk Out в SVN и TFS это разные понятия).
Единственное — нужен поднятый коннект к TFS все время работы.

С другой, стороны, если посмотреть на 2012 TFS (который позволяет хранить изменения локально, без обращения к серверу) — то вообще от SVN с ходу не отличить.

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

МР>А чем в таком сценарии TFS проигрывает AnkhSVN?

В основном — досадные мелочи в UI. Большая часть действительно нужных действий в анке делается в 1 клик. Что больше всего раздражает:

1. Показать историю по конкретному проекту. В ankh: view project history в контекстном меню, в TFS, думаете, сами знаете

2. Сам просмотр истории. Это отдельная больная тема. В анке содержимое коммита (чанжсета) просто выводится при выборе пункта в истории, файлы вне текущего проекта выводятся серым шрифтом. В TFS — двойной щелчок и ждёёём пока оно прогрузится, затем выбираем из содержимого коммита только относящееся к нужному проекту. В результате если с свн-ом я уже нашёл возможное место где всё поломалось и чиню сам, или прошу починить поломавшего, в tfs я только добираюсь в source control до проекта где оно поломалось и просматриваю коммиты.

3. Pending changes. В анке и в старых TFS это очень удобная панель управления для всех основных действий — обновление до последней/заданной версии, просмотр изменений для коммита, группировка по change list *(бесценная вещь когда надо растащить изменения в несколько коммитов), undo, просмотр истории etc. Всё ненужное убрано на отдельные вкладки/в контекстное меню, панель можно расположить горизонтально — одновременно видны длинные пути и не занимаем лишнее место на экране. Для больших коммитов предусмотрено отдельное окно — чтобы не растягивать саму панель и не отвлекаться на ненужные при коммите остальные панели студии.

В tfs 2012-13, ui переработали, но на подгонку под сценарии использования забили целиком и полностью. Панель вертикальная, куча места занята визуальным мусором (что самое смешное — он выводится контрастным чёрным шрифтом/глифами). Всё действительно важное — кнопки коммита/список файлов — выводятся двумя отдельными блоками. Список файлов (из-за блеклых иконок) теряется вообще. Для комментария к коммиту отведено мааленькое поле в 1 строчку, обновить до последней версии нельзя... Если честно, pending changes в vs2013 хуже вообще во всём

4. Обновление до конкретного чанжсета, при условии что номера чанжсета не помнишь. В анке подробности для каждого коммита видны сразу. В VS2013 — только по пункту меню — получаем ещё одно модальное окно с changeset details.

Не, жить можно конечно, но неудобно.

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

S>В основном — досадные мелочи в UI. Большая часть действительно нужных действий в анке делается в 1 клик.
Ну, наверное даже и не возразить — все так.
Я, видимо, за 2 года ужет так привык, что не замечаю и просто забыл как бывает иначе.

04.11.2013 14:43, Михаил Романов пишет:

> Я, видимо, за 2 года ужет так привык, что не замечаю и просто забыл как
> бывает иначе.
Во-во. Сначала было тяжело, потом привык. Хуже, когда потом привыкшие
начинают яростно продвигать подобные неудобства.

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

V>Во-во. Сначала было тяжело, потом привык. Хуже, когда потом привыкшие
V>начинают яростно продвигать подобные неудобства.
Да как-то с самого начала особых неудобств не испытывал.

04.11.2013 14:55, Михаил Романов пишет:

> Да как-то с самого начала особых неудобств не испытывал.
После SVN и даже CVS и клиентов к ним (не говорю уже о более
современных), мелкомягкие поделия жутко неудобны. К хорошему привыкаешь
быстро.

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

V>После SVN и даже CVS и клиентов к ним (не говорю уже о более
V>современных), мелкомягкие поделия жутко неудобны. К хорошему привыкаешь
V>быстро.
Кому как, видимо.
Некоторым коллегам действительно было непривычно/неудобно. Мне же вполне нормально.