2010-11-02

Вышел Plastic SCM Community Edition

Добрейшего.

Пропустил вчера, сегодня исправляюсь.
Codice Software, выпускающая Plastic SCM, обзор которого я не так давно делал, решила пойти навстречу малым командам и выпустила Plastic SCM, Community Edition. Это всё тот же Пластик, только обновилась схема лицензирования. Команды до 15 человек могут ставить его себе безвоздмездно, то есть даром. Ну что, неплохой подарок. Стоял бы сейчас передо мной вопрос выбора системы управления исходным кодом - думаю, не удержался бы и внедрил на пробу.

Кстати, как раз вчера они выпустили ещё и новую версию, Plastic 3.0.7, с кучей фенечек для интеграции с MS Visual Studio. Выглядит приятно.

Кто не пробовал, но интересуется тематикой бложика - не побрезгуйте, зацените.

19 комментариев:

  1. Этот комментарий был удален автором.

    ОтветитьУдалить
  2. Этот комментарий был удален автором.

    ОтветитьУдалить
  3. Удивительный проект. Написан на с# (Mono), стоит 500$ на разработчика.

    С такой ценой, наверное, удачно придумано - шансы на внедрение в крупные корпорации повышаются :)

    ОтветитьУдалить
  4. Поставил. Первые ощущения.
    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 - мама, все очень плохо.

    ОтветитьУдалить
  5. Ну что сказать - авторы вдохновлялись в первую очередь ClearCase и взяли оттуда концепцию config specs и динамического вью.
    Это подразумевает, что репо находится "где-то" (неважно - на твоей машине или на удаленной), а ты с ней работаешь. И путем изменения конфигспека (описания конфигурации, т.е. версий твоих рабочих продуктов), ты мгновенно получаешь срез исходников, нужных тебе.

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

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

    Атомный тул. Кабы не цена :)

    ОтветитьУдалить
  6. Я ничего не понял :)

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

    Реляция ведь такая тут: один ws-один репозиторий-один компонент. Почему просто не переключиться на нужную ветку/метку ?


    >Именно поэтому...требуется явно сказать системе - "я правлю этот файл на этой ветке, взяв за основу последнюю версию на ветке"

    Откуда вывод-то такой ? Система может сама определить, что я изменил файлы в рабочем пространстве и сделать ветку постфактум.

    Кроме того, это не обязательный процесс, можно работать в привычном svn/git стиле. Поменял файлы - commit(checkin).

    ОтветитьУдалить
  7. > Почему просто не переключиться на нужную ветку/метку ?

    Поменял конфигспек - переключился на другую ветку, всё просто.

    Причем, путем изменения КСа ты можешь брать разные ветки для разных элементов! То есть свой компонент ты хочешь менять на своей ветке - ты её указываешь. А другие компоненты ты хочешь брать по предыдущему бэйзлайну - его и указываешь. А ещё какие-то файлы хочешь взять с ветки другого разработчика - тоже указываешь.
    И получается, что описав конфигурацию с разным набором веток и бэйзлайнов - ты это всё сразу у себя и получаешь.
    То есть тут надо просто забыть на секунду парадигму SVN-а, где переключение на ветку влечет за собой переключение на неё всего WS. Нет, тут можно частями брать оттуда, откуда надо.

    > Кроме того, это не обязательный процесс

    Тут могу ошибаться - давно продукт смотрел. Но это было бы логично, чекаут/чекин по факту. Я говорил про модель, принятую в КлирКейсе.

    ОтветитьУдалить
  8. >То есть свой компонент ты хочешь менять на своей ветке - ты её указываешь

    Т.е. в одном репозитарии лежит несколько компонентов с разной версионностью ? А ветки, тем не менее, глобальны по всему репозиторию.

    ОтветитьУдалить
  9. В одном репо лежит всё сразу (ну, из того, что туда положили или синхронизировали из других репо). Соответственно - ветки, версии, метки - да, глобальны по репозиторию, всё доступно всем, кто имеет доступ к репо. Это и позволяет на лету менять конфигурацию и тут же её получать.

    ОтветитьУдалить
  10. Я правильно понимаю, что вместо

    http://android.git.kernel.org/

    в Plastic делается один репозиторий и каждый себе берет нужное через selector ?

    ОтветитьУдалить
  11. Ну вообще Пластик - система распределенная. Т.е. репов может быть столько, сколько надо. И соответственно, можно или подключаться к каждому из них для полноценной работы, или обмениваться инфой.

    ОтветитьУдалить
  12. Хорошо, поставим вопрос по другому :)

    Я правильно понимаю, что вместо

    http://android.git.kernel.org/

    в Plastic МОЖНО сделать один репозиторий и каждый будет себе брать нужное через selector, и с версионностью компонентов будет все в порядке ?

    ОтветитьУдалить
  13. Да, можно :)

    Правда, не совсем понял, что подразумевается под версионностью компонетов... Компоненты состоят из обычных configuration items, так что если с версиями CI всё впорядке - то и компоненты будут в целостности.

    ОтветитьУдалить
  14. >что подразумевается под версионностью компонетов

    Каждый компонент имеет свой набор релизов и базовых конфигураций.

    Я вот так сходу не могу представить, не будет ли "кривизны" если метки и ветки глобальны по репозиторию.

    ОтветитьУдалить
  15. > если метки и ветки глобальны по репозиторию

    Ну как тебе сказать... Тут по опеделению не моэет быть кривизны - ведь всё в одном месте, ничего нигде не затерялось.. откуда кривизна? Эта модель появилась гораздо раньше распределенной модели - и именно так всё и делалось до середины 2000-х годов :) Вся классика жанра была придумана именно с её использованием :)

    ОтветитьУдалить
  16. Ну вроде как все должно работать, но мозг поскрипывает :).

    Давай рассмотрим пример, если можно.

    Вот у меня в репозитории 10 компонентов, мне нужно в версии В16 Компонент9 добавить две задачи. Сейчас выпущена В15. У других компонентов свои версии, от 1 до 1000.

    Откуда брать базовую версию и куда потом интегировать задачи ?

    Вроде как

    -Базовую версию брать с метки Компонент9_В15
    -Задачи создавать в ветках Компонент9_задача123, Компонент9_задача124

    Но куда складывать потом все это ? В trunk/main ?

    ОтветитьУдалить
  17. > Но куда складывать потом все это ? В trunk/main ?

    Складывай на ту ветку, которая на проекте считается выделенной для хранения бэйзлайнов. Для разных компонентов это могут быть разные ветки - но это не помеха для того же Пластика, где можно комбинировать разные ветки в одном срезе.

    ОтветитьУдалить
  18. Судя по
    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"

    ОтветитьУдалить
  19. Честно говоря, так глубоко не копался у них... Что тут сказать - плохо это, недоработка. Думается, рано или поздно они с этим что-то должны сделать.

    ОтветитьУдалить

Примечание. Отправлять комментарии могут только участники этого блога.