Добрейшего.
Пропустил вчера, сегодня исправляюсь.
Codice Software, выпускающая Plastic SCM, обзор которого я не так давно делал, решила пойти навстречу малым командам и выпустила Plastic SCM, Community Edition. Это всё тот же Пластик, только обновилась схема лицензирования. Команды до 15 человек могут ставить его себе безвоздмездно, то есть даром. Ну что, неплохой подарок. Стоял бы сейчас передо мной вопрос выбора системы управления исходным кодом - думаю, не удержался бы и внедрил на пробу.
Кстати, как раз вчера они выпустили ещё и новую версию, Plastic 3.0.7, с кучей фенечек для интеграции с MS Visual Studio. Выглядит приятно.
Кто не пробовал, но интересуется тематикой бложика - не побрезгуйте, зацените.
Этот комментарий был удален автором.
ОтветитьУдалитьЭтот комментарий был удален автором.
ОтветитьУдалитьУдивительный проект. Написан на с# (Mono), стоит 500$ на разработчика.
ОтветитьУдалитьС такой ценой, наверное, удачно придумано - шансы на внедрение в крупные корпорации повышаются :)
Поставил. Первые ощущения.
ОтветитьУдалить1) GUI очень своеобразный, надо привыкать.
2) Сделал репозиторий, поместил туда файлы. Открыл по быстрому файл в текстовом редакторе - сюрприз - он read-only. Потыкался в меню - надо вроде делать check-out, тогда атрибут снимается. Потом, соответственно, нужен check-in. Не смог поверить. Пошел на сайт читать доки. Да, так и есть - в GUI надо найти файл, потом ему сделать check-out, потом отредактировать, потом check-in. В голове возникла "ностальгия" по Source Safe :).
3) К счастью, нашел как этот ужас отключить :) :) :)
4) Merge. Это просто сказочно. Сделал две ветки, в обоих изменил один и тот же файл, в одной добавил функцию func11() и ПЕРЕМЕСТИЛ по тексту уже имеющуюся функцию func4() в другое место, в другой добавил еще функцию func12(). Merge прошел АВТОМАТИЧЕСКИ !!! Потрясно. Ради эксперимента сделал то же самое в eclipse + subversion - мама, все очень плохо.
Ну что сказать - авторы вдохновлялись в первую очередь ClearCase и взяли оттуда концепцию config specs и динамического вью.
ОтветитьУдалитьЭто подразумевает, что репо находится "где-то" (неважно - на твоей машине или на удаленной), а ты с ней работаешь. И путем изменения конфигспека (описания конфигурации, т.е. версий твоих рабочих продуктов), ты мгновенно получаешь срез исходников, нужных тебе.
Именно поэтому (потому что дело фактически происходит "где-то", в неподконтрольном тобой просотранстве) требуется явно сказать системе - "я правлю этот файл на этой ветке, взяв за основу последнюю версию на ветке". Потому что то же самое может попытаться сделать другой человек.
Кроме того, что самое примечательное, по чекауту элемента можно производить нужные действия - в первую очередь автоматически отращивать ветку. Т.е. находимся на какой-то ветке, делаем чекаут и - если это прописано в конфигспеке - автоматом создаем ветку, на которой и продолжаем работу. Т.е. вопрос о том, что надо бы не забыть отрастить ветку для изменяемых элементов - он даже не стоит. Всё прозрачно.
Атомный тул. Кабы не цена :)
Я ничего не понял :)
ОтветитьУдалить>И путем изменения конфигспека (описания конфигурации, т.е. версий твоих рабочих продуктов), ты мгновенно получаешь срез исходников, нужных тебе.
Реляция ведь такая тут: один ws-один репозиторий-один компонент. Почему просто не переключиться на нужную ветку/метку ?
>Именно поэтому...требуется явно сказать системе - "я правлю этот файл на этой ветке, взяв за основу последнюю версию на ветке"
Откуда вывод-то такой ? Система может сама определить, что я изменил файлы в рабочем пространстве и сделать ветку постфактум.
Кроме того, это не обязательный процесс, можно работать в привычном svn/git стиле. Поменял файлы - commit(checkin).
> Почему просто не переключиться на нужную ветку/метку ?
ОтветитьУдалитьПоменял конфигспек - переключился на другую ветку, всё просто.
Причем, путем изменения КСа ты можешь брать разные ветки для разных элементов! То есть свой компонент ты хочешь менять на своей ветке - ты её указываешь. А другие компоненты ты хочешь брать по предыдущему бэйзлайну - его и указываешь. А ещё какие-то файлы хочешь взять с ветки другого разработчика - тоже указываешь.
И получается, что описав конфигурацию с разным набором веток и бэйзлайнов - ты это всё сразу у себя и получаешь.
То есть тут надо просто забыть на секунду парадигму SVN-а, где переключение на ветку влечет за собой переключение на неё всего WS. Нет, тут можно частями брать оттуда, откуда надо.
> Кроме того, это не обязательный процесс
Тут могу ошибаться - давно продукт смотрел. Но это было бы логично, чекаут/чекин по факту. Я говорил про модель, принятую в КлирКейсе.
>То есть свой компонент ты хочешь менять на своей ветке - ты её указываешь
ОтветитьУдалитьТ.е. в одном репозитарии лежит несколько компонентов с разной версионностью ? А ветки, тем не менее, глобальны по всему репозиторию.
В одном репо лежит всё сразу (ну, из того, что туда положили или синхронизировали из других репо). Соответственно - ветки, версии, метки - да, глобальны по репозиторию, всё доступно всем, кто имеет доступ к репо. Это и позволяет на лету менять конфигурацию и тут же её получать.
ОтветитьУдалитьЯ правильно понимаю, что вместо
ОтветитьУдалитьhttp://android.git.kernel.org/
в Plastic делается один репозиторий и каждый себе берет нужное через selector ?
Ну вообще Пластик - система распределенная. Т.е. репов может быть столько, сколько надо. И соответственно, можно или подключаться к каждому из них для полноценной работы, или обмениваться инфой.
ОтветитьУдалитьХорошо, поставим вопрос по другому :)
ОтветитьУдалитьЯ правильно понимаю, что вместо
http://android.git.kernel.org/
в Plastic МОЖНО сделать один репозиторий и каждый будет себе брать нужное через selector, и с версионностью компонентов будет все в порядке ?
Да, можно :)
ОтветитьУдалитьПравда, не совсем понял, что подразумевается под версионностью компонетов... Компоненты состоят из обычных configuration items, так что если с версиями CI всё впорядке - то и компоненты будут в целостности.
>что подразумевается под версионностью компонетов
ОтветитьУдалитьКаждый компонент имеет свой набор релизов и базовых конфигураций.
Я вот так сходу не могу представить, не будет ли "кривизны" если метки и ветки глобальны по репозиторию.
> если метки и ветки глобальны по репозиторию
ОтветитьУдалитьНу как тебе сказать... Тут по опеделению не моэет быть кривизны - ведь всё в одном месте, ничего нигде не затерялось.. откуда кривизна? Эта модель появилась гораздо раньше распределенной модели - и именно так всё и делалось до середины 2000-х годов :) Вся классика жанра была придумана именно с её использованием :)
Ну вроде как все должно работать, но мозг поскрипывает :).
ОтветитьУдалитьДавай рассмотрим пример, если можно.
Вот у меня в репозитории 10 компонентов, мне нужно в версии В16 Компонент9 добавить две задачи. Сейчас выпущена В15. У других компонентов свои версии, от 1 до 1000.
Откуда брать базовую версию и куда потом интегировать задачи ?
Вроде как
-Базовую версию брать с метки Компонент9_В15
-Задачи создавать в ветках Компонент9_задача123, Компонент9_задача124
Но куда складывать потом все это ? В trunk/main ?
> Но куда складывать потом все это ? В trunk/main ?
ОтветитьУдалитьСкладывай на ту ветку, которая на проекте считается выделенной для хранения бэйзлайнов. Для разных компонентов это могут быть разные ветки - но это не помеха для того же Пластика, где можно комбинировать разные ветки в одном срезе.
Судя по
ОтветитьУдалитьhttp://www.plasticscm.net/forum193/default.aspx?g=posts&t=151
не так все гладко (было?) у них с селекторами
dpadlewski хотел создать репо для библиотек, что понятно, крутили-крутили, в результате:
"is achieving the result that you want, but it's limited to one library since you can only specify one repository rule for a given repository (the same rep name can't appear more than once)".
И под занавес ему порекомендовали завести репо под каждую библиотеку
The ideal way to achieve what you want is to have separate repositories for each library, so you can have a selector like:
repository "Log4Net" mount "/lib/Log4net"
path "/"
lb "Log4Net1.2.10.0"
repository "Antlr" mount "/lib/Antlr"
path "/"
lb "Antlr0.96"
repository "JazzDomain"
path "/"
smartbranch "/main/CollectionsRefactor"
Честно говоря, так глубоко не копался у них... Что тут сказать - плохо это, недоработка. Думается, рано или поздно они с этим что-то должны сделать.
ОтветитьУдалить