Если оставить для другого треда споры о необходимости интеграции SVN в IDE и посмотреть на сегодняшнее положение дел, то вот что мы имеем:

• AnkhSVN — единственный относительно стабильный продукт, и единственный не реализующий MSSCC API. Всё ещё находится в бета статусе, о комфортной работе речи нет. Диалоги и юзабельные, pending checkins не работает, тормозит при загрузке.
  
• PushOk SVN Proxy — платный, да и не работает.
  
• Subway — мёртвый.
  
• SVNScc — мёртвый.
  
• chmsubscc — не работает.
  
• sourcecross — мёртвый, хотя и есть невнятные попытки возродиться.
  
• TortoiseSVNSCC — не работает.

Это результаты беглого просмотра на простом Windows .NET проекте в VS2003 и VS2005. На объёмном проекте и при более продолжительной работе, скорее всего, выявятся дополнительные проблемы.
А что хотелось бы иметь? Стабильную реализацию провайдера MSSCC API, предоставляющую в полном объёме функциональность последней версии Subversion. По крайней мере:

• статус текущей версии
  
• историю изменений файла, папки
  
• диф выбранных версий
  
• автоматическая блокировка нетекстовых файлов
  
• разрешение конфликтов
  
• переименование и перемещение файлов
  
• выполнение команд удалённо, в репозитарии
  
• удобная работа с клавиатуры
  
• принятие русского текста

И всё это не выходя из IDE. В этом списке даже нет ветвления, переключения между ветками и атрибутов.
Вообще, печально наблюдать отсутствие открытого стандарта на API к VCS. Мне кажется, при наличии такового мы бы сейчас имели более широкий выбор.
Вывод: на сегодняшний день, AnkhSVN — единственный продукт, который можно считать рабочим, но не реализуя MSSCC API, вряд ли ему суждено стать массовым.

Да, возможность интеграции в данном случае рассматривалась для платформы Windows и IDE: VS6, VB6, VS2003, VS2005, PowerBuilder и тому подобное, поддерживающее MSSCC API.

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

F>

AnkhSVN — единственный относительно стабильный продукт, и единственный не реализующий MSSCC API.

SCC рассчитан на модель VSS. SVN мягко говоря под нее не подходит. Так что толку от поддержки SCC API для SVN 0.

... << RSDN@Home 1.2.0 alpha rev. 644 on Windows XP 5.1.2600.131072>>

AVK>SCC рассчитан на модель VSS. SVN мягко говоря под нее не подходит. Так что толку от поддержки SCC API для SVN 0.

Какие из перечисленных выше функций не могут быть реализованы через SCC API? Или речь о чём-то другом? Что такое "модель VSS" в таком случае?

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

AVK>>SCC рассчитан на модель VSS. SVN мягко говоря под нее не подходит. Так что толку от поддержки SCC API для SVN 0.

F>Какие из перечисленных выше функций не могут быть реализованы через SCC API?

статус текущей версии

Набор статусов VSS и SVN практически не пересекается, а SCC заточено именно под первый.

историю изменений файла, папки

Имеет довольно слабое отношение к SCC.

диф выбранных версий

Имеет довольно слабое отношение к SCC.

автоматическая блокировка нетекстовых файлов

В SCC поддержки такого нет. Да и не нужно это SVN.

разрешение конфликтов

Имеет довольно слабое отношение к SCC.

переименование и перемещение файлов

Ну вот единственное где SCC для SVN мог бы быть полезен. Но AnkhSVN вроде бы это обеспечивает, хоть и не через SCC (через внутренние интерфейсы поддержки SCC студии).

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

Вобще не имеет отношения к SCC.

удобная работа с клавиатуры

С чем?

принятие русского текста

Вобще не имеет отношения к SCC.

F> Или речь о чём-то другом? Что такое "модель VSS" в таком случае?

Модель обрабатываемых данных и поведения пользователя. В случае SVN и VSS отличается очень сильно. Например основное, что упрощает SCC — автоматический чекаут файлов. В SVN аналогичная операция просто отсутствует.

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

AVK>Ну вот единственное где SCC для SVN мог бы быть полезен. Но AnkhSVN вроде бы это обеспечивает, хоть и не через SCC (через внутренние интерфейсы поддержки SCC студии).
Кстати, ты не пробовал использовать AnkhSVN вместе с Решарпером? Год назад, когда я смотрел AnkhSVN, то переименование делалось только через дополнительную команду в контекстном меню. Авторы это объясняли тем, что от Студии не приходит необходимых событий.

Соответственно, вопрос в том, если я Решарпером переименую класс, то увидит ли это изменение AnkhSVN?

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

Mab>Кстати, ты не пробовал использовать AnkhSVN вместе с Решарпером?

Я его один раз поставил, студия зависла на сборке С++ного проекта и я его снес. С тех пор больше не ставил.

Mab> Год назад, когда я смотрел AnkhSVN, то переименование делалось только через дополнительную команду в контекстном меню. Авторы это объясняли тем, что от Студии не приходит необходимых событий.

Гонят. IVsTrackProjectDocumentsEvents.OnAfterRenameFiles

Mab>Соответственно, вопрос в том, если я Решарпером переименую класс, то увидит ли это изменение AnkhSVN?

А зачем это ему? VCS не классы волнуют, а файлы. Переименование файла должен увидеть.

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

AVK>Я его один раз поставил, студия зависла на сборке С++ного проекта и я его снес. С тех пор больше не ставил.
Понятно

AVK>Гонят. IVsTrackProjectDocumentsEvents.OnAfterRenameFiles
В том-то и проблема, что OnAfterRenameFiles. А при работе с svn нужно ловить Before. Либо после After возвращать файл назад и делать svn mv. Второй вариант авторам плагина не понравился, поэтому они решили, что пользователей надо приучать переименовывать с помощью их собственной мегакоманды. По крайней мере, такое у меня осталось впечатление от чтения FAQ.

AVK>А зачем это ему? VCS не классы волнуют, а файлы. Переименование файла должен увидеть.
Решарпер при переименовании классов переименовыывает файлы, используя стандартное API студии. AnkhSVN события от этого API не использует (не использовал?). Отсюда и вопрос.

F>>статус текущей версии
AVK>Набор статусов VSS и SVN практически не пересекается, а SCC заточено именно под первый.
По моему, такой список статусов вполне достаточен для работы из IDE:

• без изменений
  
• новый
  
• удалённый
  
• изменённый
  
• конфликт
  
• вне контроля версий
  
• взят в единоличное владение
  
• заблокирован другим пользователем

Из этого списка только "конфликт" под вопросом поддержки его в SCC API.

F>>историю изменений файла, папки
F>>диф выбранных версий
F>>разрешение конфликтов
AVK>Имеет довольно слабое отношение к SCC.
Операция или предусмотрена в API, или нет. История предусмотрена — из окна истории можем сделать и диф. Разрешение конфликтов под вопросом.

F>>выполнение команд удалённо, в репозитарии
F>>принятие русского текста
AVK>Вобще не имеет отношения к SCC.

F>>переименование и перемещение файлов
AVK>Ну вот единственное где SCC для SVN мог бы быть полезен. Но AnkhSVN вроде бы это обеспечивает, хоть и не через SCC (через внутренние интерфейсы поддержки SCC студии).
В VS2005 перемещение происходит и в репозитарии. Можно надеятся, что реализация работает через SCC API.

F>>удобная работа с клавиатуры
AVK>С чем?
С пользовательским интерфейсом, предоставляемым плагином. Для примера попробуй поработать с AnkhSVN без мышки.

F>>автоматическая блокировка нетекстовых файлов
AVK>В SCC поддержки такого нет. Да и не нужно это SVN.
AVK>Модель обрабатываемых данных и поведения пользователя. В случае SVN и VSS отличается очень сильно. Например основное, что упрощает SCC — автоматический чекаут файлов. В SVN аналогичная операция просто отсутствует.
Речь идёт о необходимости сериализации доступа к бинарным файлам, в SVN это реализуется командой lock. Первый вопрос: какие есть аргументы в пользу того, что это не нужно?

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

Mab>В том-то и проблема, что OnAfterRenameFiles. А при работе с svn нужно ловить Before.

Зачем? Впрочем есть и IVsTrackProjectDocumentsEvents2.OnQueryRenameFiles.

Mab> Либо после After возвращать файл назад и делать svn mv.

Не надо ничего возвращать, нужно просто entries подкорректировать.

Mab> Второй вариант авторам плагина не понравился, поэтому они решили, что пользователей надо приучать переименовывать с помощью их собственной мегакоманды. По крайней мере, такое у меня осталось впечатление от чтения FAQ.

Ламеры они. Вопрос с Rename стоит и в случае VSS, соотв. весь соотв. функционал должен наличествовать и работать.

AVK>>А зачем это ему? VCS не классы волнуют, а файлы. Переименование файла должен увидеть.
Mab>Решарпер при переименовании классов переименовыывает файлы, используя стандартное API студии.

Ну значит должно работать.

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

F>>>историю изменений файла, папки
F>>>диф выбранных версий
F>>>разрешение конфликтов
AVK>>Имеет довольно слабое отношение к SCC.
F>Операция или предусмотрена в API, или нет. История предусмотрена — из окна истории можем сделать и диф.

Единственное что там предусмотрено — контекстное меню. Для этого SCC не нужен.

AVK>>Ну вот единственное где SCC для SVN мог бы быть полезен. Но AnkhSVN вроде бы это обеспечивает, хоть и не через SCC (через внутренние интерфейсы поддержки SCC студии).
F>В VS2005 перемещение происходит и в репозитарии. Можно надеятся, что реализация работает через SCC API.

Эта реализация может работать напрямую, пользуясь IVsTrackProjectDocumentsEvents2.

F>>>удобная работа с клавиатуры
AVK>>С чем?
F>С пользовательским интерфейсом, предоставляемым плагином.

SCC плагин практически не предоставляет никакого пользовательского интерфейса. А вот кастомный вполне может.

F> Для примера попробуй поработать с AnkhSVN без мышки.

А с поддержкой VSS?

F>Речь идёт о необходимости сериализации доступа к бинарным файлам, в SVN это реализуется командой lock.

Попробуй ответить на простой вопрос — почему эта команда появилась недавно?

F> Первый вопрос: какие есть аргументы в пользу того, что это не нужно?

А зачем тебе lock?

AVK>SCC плагин практически не предоставляет никакого пользовательского интерфейса.
VSS, например, на каждую операцию изменения может вываливать диалог для ввода комментариев. Диф текущих изменений и история изменений — это тоже операции, включённые в SCC API, на которые вываливаются соответствующие диалоги.

F>> Для примера попробуй поработать с AnkhSVN без мышки.
AVK>А с поддержкой VSS?
В проектах под VSS (VS2003) я не использую мышку при выполнении операций с репозитарием.

F>>Речь идёт о необходимости сериализации доступа к бинарным файлам, в SVN это реализуется командой lock.
AVK>Попробуй ответить на простой вопрос — почему эта команда появилась недавно?
Вероятно, она была реализована в порядке очерёдности. То, что она реализована, уже говорит о том, что она востребована.

F>> Первый вопрос: какие есть аргументы в пользу того, что это не нужно?
AVK>А зачем тебе lock?
Что бы предотвратить потерю времени при параллельной модификации бинарных файлов. Смёржить их нельзя, получается что работа одного человека просто выбрасывается — все изменения, которые он сделал, он дожен сделать опять уже в новой версии, а пока он вносит изменения, файл опять мог измениться... Можно говорить, что аналогичная ситуация и с текстовыми файлами, но слияние и разрешение конфликтов в текстовых файлах гораздо проще и выполняется гораздо быстрее, поэтому потеря времени на разрешение конфликтов в текстовых файлах незначительна по сравнению с преимуществом параллельной разработки. С бинарными файлами наоборот — выигранное время при параллельной разработке поглащается временем на разрешение конфликтов.
На примере проектов на C# бинарные документы это: документация (doc), модели (XDE), графика (ico, png и т.д.). С ресурсами форм ситуация двоякая: с одной стороны это текстовый файл (xml), с другой — в него могут сериализоваться и бинарные данные.
Собственно, комментарии разработчиков SVN:

Subversion 1.2 Release Notes
File Locking
"Locking" is a long-requested feature, often known in other systems as "reserved checkouts". While Subversion is still primarily a copy-modify-merge system focused on parallel development, there is widespread acknowledgement that not all files are easily mergeable — binary files in particular, such as artwork, compressed files, proprietary binary formats, or any other non-line-based data.
The goal of the new locking feature is twofold. First, provide a means to force serialized write-access to a file. Second, provide a communication mechanism to prevent users from wasting time on unmergable changes.

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

AVK>>SCC плагин практически не предоставляет никакого пользовательского интерфейса.
F>VSS, например, на каждую операцию изменения может вываливать диалог для ввода комментариев.

А SVN вобще подобного не отслеживает.

F> Диф текущих изменений и история изменений — это тоже операции, включённые в SCC API, на которые вываливаются соответствующие диалоги.

Я тебе уже написал — вся поддержка заключается в добавлении пунктов в контекстное меню.

AVK>>А с поддержкой VSS?
F>В проектах под VSS (VS2003) я не использую мышку при выполнении операций с репозитарием.

А что используешь?

AVK>>Попробуй ответить на простой вопрос — почему эта команда появилась недавно?
F>Вероятно, она была реализована в порядке очерёдности.

Нет, просто нужды в ней особой нет. Ты можешь конечно не поверить, но все мои знакомые, пользующиеся SVN (а таких немало), операцию lock не используют вобще.

F>>В проектах под VSS (VS2003) я не использую мышку при выполнении операций с репозитарием.
AVK>А что используешь?
Клавиатуру. Что такого в этом пунтке, что мы ходим по кругу? Пользовательский интерфейс должен быть максимально адаптирован для работы с клавиатуры. Плагин, не зависимо от схемы интеграции, предоставляет элементы интерфейса и должен удовлетровать этому требованию. VSS плагин этому требованию удовлетворяет.

AVK>>>Попробуй ответить на простой вопрос — почему эта команда появилась недавно?
F>>Вероятно, она была реализована в порядке очерёдности.
AVK>Нет, просто нужды в ней особой нет. Ты можешь конечно не поверить, но все мои знакомые, пользующиеся SVN (а таких немало), операцию lock не используют вобще.
Без аргументации это так и останется вопросом веры.
Описанная выше проблема возникает при параллельной работе над бинарным файлом. Есть три варианта, почему проблема может не возникать в проекте с несколькими разработчиками:

1. они не работают с бинарными файлами
   
2. они работают с бинарными файлами, но волей случая до сих пор не делали одновременных изменений в одном файле
   
3. они работают с бинарными файлами, и доступ разграничивают административно (например, сегодня файл правит этот разработчик, завтра — будет время другого)

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

AVK>Не надо ничего возвращать, нужно просто entries подкорректировать.
Они же не работают с WC напрямую, а используют API svn-а.

Mab>>Решарпер при переименовании классов переименовыывает файлы, используя стандартное API студии.
AVK>Ну значит должно работать.

Поигрался с последним билдом AnkhSVN. Диагноз -- в морг. Основные операции (add/remove/rename/move) работают через раз. Единожды переименованный файл второй раз переименовать не закоммитив уже нельзя. Я понимаю, что это ограничение SVN, но работать получается невозможно.

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


F>Вывод: на сегодняшний день, AnkhSVN — единственный продукт, который можно считать рабочим, но не реализуя MSSCC API, вряд ли ему суждено стать массовым.

чё то не мсог я в нём из студии посмотерть изменения файла (историю) и посмотреть выбранную ревизию файла... мож не так смотрел ?

А>чё то не мсог я в нём из студии посмотерть изменения файла (историю) и посмотреть выбранную ревизию файла... мож не так смотрел ?
Опиши конкретнее, в чём проблема — может, смогу помочь.

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


А>>чё то не мсог я в нём из студии посмотерть изменения файла (историю) и посмотреть выбранную ревизию файла... мож не так смотрел ?
F>Опиши конкретнее, в чём проблема — может, смогу помочь.

Хочу посмотреть лог изменений файла и поглядеть на разницу между некоторыми ревизиями. командами svn это без проблем, tortoise тоже отлично делает, плагин этот выдаёт лог изменений в xml формате, форматированный и обработанный студией, но страничка мёртвая — diff-ы по ревизиям на ней сотреть нельзя...

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

AVK>>Не надо ничего возвращать, нужно просто entries подкорректировать.
Mab>Они же не работают с WC напрямую, а используют API svn-а.

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

Mab>Поигрался с последним билдом AnkhSVN. Диагноз -- в морг. Основные операции (add/remove/rename/move) работают через раз.

Вобщем надо свой плагин писать. Возьмешься?

Mab> Единожды переименованный файл второй раз переименовать не закоммитив уже нельзя. Я понимаю, что это ограничение SVN, но работать получается невозможно.

Нет такого ограничения в SVN. Возможно такое ограничение есть в SVN client API, ну так оно не икона. Структура WC прозрачна и проста, можно вобще стандартным API не пользоваться.

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


А>>чё то не мсог я в нём из студии посмотерть изменения файла (историю) и посмотреть выбранную ревизию файла... мож не так смотрел ?
F>Опиши конкретнее, в чём проблема — может, смогу помочь.

да и ветки/тэги кстатити делать не умеет Опять же всё свожится к использованию для этого tortoise...