VSS в Subversion - PullRequest
       32

VSS в Subversion

3 голосов
/ 16 июня 2009

Я исследую потенциальный переход от SourceSafe к Subversion, и мы боремся с парадигмой edit / merge / commit vs. checkout / update / checkin. Основная проблема заключается в том, как узнать, какие файлы извлекаются с помощью Subversion (и для кого)?

Есть ли в VSS Subversion, эквивалентный «Поиску статуса»? Или это невозможно из-за отсутствия «забронированного заказа»?

Кроме того, если мы попытаемся реализовать «зарезервированные проверки» с помощью Subversion через «блокировки», существует ли графический интерфейс (TortoiseSVN, VirtualSVN и т. Д.), Который поддерживает «блокировку проверки»?

Спасибо.

Обновление: пример, прежде чем мы сделаем сборку / выпуск, мы хотим быть абсолютно уверены, что все файлы проверены. Разработчики забывают. Поэтому нам нужно знать, какие файлы извлечены. Это возможно с Subversion? Можно ли просмотреть список извлеченных (или заблокированных) файлов? Просмотр всей кодовой базы в Explorer невозможен, есть ли какой-нибудь стиль отчета или функция поиска?

Ответы [ 8 ]

8 голосов
/ 16 июня 2009

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

Поэтому «поиск статуса» на самом деле не нужен.

SVN поддерживает концепцию блокировки, которая полезна для тех двоичных файлов, которые трудно объединить. Даже там замок не жесткий; это просто сигнал другим разработчикам: «пожалуйста, не делайте коммитов, пока я редактирую этот файл». В графическом интерфейсе SVN есть возможность блокировки файла. Вы также можете включить блокировку с помощью специального свойства svn:needs-lock.

См. Svnbook для получения дополнительной информации о блокировке: http://svnbook.red -bean.com / ru / 1.2 / svn.advanced.locking.html

8 голосов
/ 16 июня 2009

Если вы используете парадигму редактирования / слияния / фиксации (которая вам не нужна с Subversion, кстати), то на самом деле не существует такой вещи, как человек, «проверяющий» файл.

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

Разработчики опускают всю базовую линию (или, по крайней мере, часть, которую они хотят построить), и они просто редактируют все, что хотят, когда их настроение поражает. Когда они хотят проверить свои изменения обратно, вот тут и начинается слияние.

На первый взгляд, вы, как пользователь VSS, можете подумать, что регистрация файла может «стереть» изменения, внесенные в этот файл с момента его проверки. Я не понимал, как это могло сработать изначально. Хитрость заключается в том, что SVN может определить, когда кто-то еще проверял версию этого файла с тех пор, как вы его проверили, и поэтому его нужно объединить, а не просто заменить. Это умнее, чем VSS. : -)

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


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

Правильно, что модель блокировки предоставляет разработчикам возможность заявить о своем намерении изменить файл в центральном хранилище, а редактирование / объединение - нет. Инструменты, созданные для одного подхода, часто просто не имеют смысла для другого. Это один из таких случаев.

Мое предложение для вас, как инструктора, было бы попробовать небольшой (или игрушечный) проект с SVN, чтобы познакомиться с другим методом работы. Как только вы поймете это, вы сможете обернуть вокруг него голову.

2 голосов
/ 01 июля 2009

Матовый,

Как бывший пользователь VSS, который перешел в SVN, я могу понять ваше разочарование. Тем не менее, я считаю, что вы уже ответили на свой вопрос. Вы указали, что боретесь с переходом от мышления «блокировать / редактировать / разблокировать» к мышлению «обновить / редактировать / зафиксировать», и это действительно является источником вашего разочарования. Я знаю, потому что я был там сам.

По сути, я думаю, что проблема, которую вы пытаетесь решить, основана на мышлении "блокировать / редактировать / разблокировать" ... которое (как уже было сказано другими ответами здесь) является "моделью ограничения безопасности", то есть мы хотим защитить вас от совершения каких-либо вредных действий, поэтому мы ограничим ваш уровень доступа. Мышление «обновить / отредактировать / зафиксировать» в основном использует подход, при котором 90% времени пользователь (в данном случае разработчик) заслуживает доверия и знает, что он делает, поэтому мы позволим вам делать то, что вы хотите, и предоставлять вам инструменты, с которыми можно справиться небольшое количество раз, когда вы попадаете в неприятности.

Если я могу быть настолько смелым, чтобы переформулировать проблему, которую вы пытаетесь решить, это:

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

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

Могу я спросить, сколько раз это на самом деле случалось для вас? После того, как это будет сделано один раз, сколько раз разработчик сделает это за секунду (или позже)? Если бы они были постоянным нарушителем, сколько раз вы, как руководитель / менеджер группы, позволили бы этому случиться до того, как разработчику «будет предложено искать возможности карьерного роста»?

Так что, в основном, мой ответ ... научите ваших разработчиков не забывать и иметь дело со случайным случаем, когда они забывают.

Я предполагаю, что, задавая вопрос, можно ли "просмотреть список извлеченных (или заблокированных) файлов?" что вы намереваетесь принудительно установить эксклюзивную блокировку всех файлов в хранилище (в противном случае в SVN нет понятия «заблокированный» файл)? Это серьезно ограничивает одно из больших преимуществ SVN (или любой другой модели SCM «обновление / изменение / принятие») перед VSS (или любой другой моделью SCM «блокировка / редактирование / разблокировка»).

Приветствие Ричард

2 голосов
/ 16 июня 2009

TortoiseSVN сообщит вам, заблокированы ли файлы, при их просмотре в обозревателе или обозревателе хранилища над файлами появится значок блокировки.

Однако стандартный метод работы SVN не блокирует / обновляет / разблокирует, как в VSS. «Оформить заказ» в SVN аналогично «получить последнюю версию» VSS.

Лично я бы избежал рабочего процесса блокировки / обновления / разблокировки. Алгоритмы слияния в SVN намного лучше, чем VSS. Блокировка / обновление / разблокировка принципиально противоположна параллельной разработке.

1 голос
/ 01 июля 2009

Я ценю все ответы / мнения. Однако, чтобы просто закрыть цикл, если вы решите использовать парадигму блокировки / редактирования / разблокировки, что возможно в Subversion, вы можете использовать TortoiseSvn для просмотра всех текущих блокировок для всех пользователей.

  • Выберите TortoiseSvn | Проверьте наличие изменений, затем выберите «Проверить хранилище».
  • Отображается список файлов.
  • В столбце «Блокировка» показан пользователь, заблокировавший файл.
1 голос
/ 16 июня 2009

Я бы действительно рекомендовал перейти на Subversion (или, честно говоря, даже ручку и бумагу) поверх VSS. Чтобы более точно ответить на ваш вопрос; используя Subversion, вам не нужно знать, кто получил файл, проверенный так же строго, как с VSS; Subversion (и разумные системы управления исходным кодом) не подходят для слияния изменений, как это делает VSS.

0 голосов
/ 26 июня 2012

Хм, я опаздываю на вечеринку, но:

http://svnbook.red -bean.com / о / 1,5 / svn.ref.svnadmin.c.lslocks.html

$ svnadmin lslocks /var/svn/repos
Path: /tree.jpg
UUID Token: opaquelocktoken:ab00ddf0-6afb-0310-9cd0-dda813329753
Owner: harry
Created: 2005-07-08 17:27:36 -0500 (Fri, 08 Jul 2005)
Expires: 
Comment (1 line):
Rework the uppermost branches on the bald cypress in the foreground.
0 голосов
/ 16 июня 2009

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

Хорошие инструменты трехстороннего слияния, такие как бесплатный SourceGear DiffMerge , позволяют очень просто разрешить случайный конфликт, если он у вас возникнет (возможно, раз в несколько месяцев для всей команды; не более).

...