subject:"Re\: Подскажите инструментарий для file release system."

  Нормально насчет воспроизводимости.  Снапшоты этой виртуальной машины тоже
  хранятся под VCS.  Просто среди смоллтоковцев люди по большей части неплохо
  образованные, и их не шокирует идея, что исходники - это не обязательно 
  текст
  на C и вообще не обязательно текст.  Они подумали головой, и эта виртуалка 
  у
 
  Хранить снапшоты под VCS, конечно можно, но толку то?
 
 Там есть информация кто и когда, может представлять интерес.
 
 Можно конечно ложить рядом README, но потом тяжело рекурсивно
 по иерархии пробегаться по этим README (которые доступны через
   NFS/FTP/HTTP) для выяснения гадил ли Вася в прошлем месяце
 и где...

Откройте для себя команду log, которая есть у любой VCS?

-- 
Unix-like -- для кинестетиков, Emacs -- для аудиалов, Mac -- для визуалов, 
Windows -- для чайников
 -- RockMover in rm279891167063140rmo...@golovolomka.net


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/871uukm15b.wl%...@ran.pp.ru

Re: Подскажите инструментарий для file release system.

2011-10-11 Пенетрантность Sergey Stremidlo

  Нормально насчет воспроизводимости.  Снапшоты этой виртуальной машины тоже
  хранятся под VCS.  Просто среди смоллтоковцев люди по большей части неплохо
  образованные, и их не шокирует идея, что исходники - это не обязательно 
  текст
  на C и вообще не обязательно текст.  Они подумали головой, и эта виртуалка у
 
 Хранить снапшоты под VCS, конечно можно, но толку то? 

В смысле как мержить или откатывать позапрошлый коммит?  Там у них своя
встроенная VCS, которая в курсе.  Там же не универсальная VM, а специфическая.

-- 
Нужны две программы - одна с интерфейсом, а другая чтобы работу делала.
Victor Wagner в aut24i$gct$1...@wagner.wagner.home


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87zkh8kmbb.wl%...@ran.pp.ru

Re: Подскажите инструментарий для file release system.


11.10.2011 01:56, Oleksandr Gavenko пишет:

Кажется в SVN в хуке можно отличать ADD от CHANGED и тут же рубать.

И вроде для FTP сервера команда STOR перезаписывает файл...
с FTP такой цели не достичь. 
в настройках фтп сервера можно указать маску создания и с помощью 
sticky-бита запретить удаление файлов.
ну и насколько помнится в pure-ftpd можно заводить разных пользователей 
при этом указывая корневую папку выше домашней, что приведет к тому что 
можно будет читать папки других пользователей.

Короче мне кажется что права можно разграничить средствами самого pure-ftpd


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e93f3c6.8000...@gmail.com

Re: Подскажите инструментарий для file release system.

2011-10-11 Пенетрантность Sergey Stremidlo

У нас предприятие было маленькое, и в итоге всё свелось к тому, что от
разграничения прав один геморрой, поэтому всё свелось к ssh и одной группе
разработчиков. Маленькое - это полтора десятка человек, которым нужен этот
доступ, и примерно столько же проектов. Практика показала, что почти в
каждый
проект может потребоваться коммит почти от любого разработчика. Поэтому
технические средства разграничения только мешали - в конце концов, не
трехлетние дети работали, интеллекта не коммититься куда не надо людям
хватало.

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

Тогда заморачиваться на разграничение прав не стоит.

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

Плохой комит встречается часто и допустим в том смысле что не будет
неожиданостью т.к. впереди тестирование и/или ревью.

Но ситуация меняется когда продукт отдается вовне... ошибки досадны
и болючи.

Прихожу к тому что бы использовать файлы CHANGES (user visible changes)
и VERSION (major.minor.fix). В момент релиза в CHANGES вноситься
дата, версия (новая) и ревизия из VCS (нужно ли?),
доправляються описания изменений,
в соответствии со степенью изменений обновляется
VERSION и происходит комит, который говорит что некто считает
(ручается) что состояние проекта отвечает перечисленым в
CHANGES свойствам и готово работать.

После комита делаем таг в соответствии с содержимым VERSION,
собираем проект с релизом на FRS (file release system).

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

В принципе по факту создания тага сервер сборок может делать релиз...

А вот тут расскажу, как это делали мы. Собственно, мы брали схему,
неоднократно описанную во всех книгах по использованию VCS, подробнее всего,
кажется, в SVN book.

Есть ствол, где идет основная разработка.

Есть feature branches - для экспериментов с отдельными идеями, иногда довольно
продвинутыми. Одна такая ветка жила два года. Но в норме идея в том, что ты
форкаешь ветку, реализуешь фичу, прогоняешь ее через тестовую ферму (была
система автоматической сборки и прогона тестов), и либо в конце концов
решаешь, что идея была дурацкая и просто убиваешь ветку, либо вливаешь
результат в основную (если точнее, то технологически ты сначала вливаешь
пропущенные изменения из ствола в свою ветку, снова тестируешь, и только потом
вливаешь результат в ствол).

Есть release branches - для подготовки релиза. По отмашке готовим релиз она
форкается от ствола, и далее в ней только правятся баги, найденные
тестировщиками.

Есть релизы - это, собственно, tag в тех VCS, которые поддерживают его
непосредственно, для svn это было конвенциональное svn copy . .../tags/v.1.0.0
Скрипт проверки на сервере не позволял менять ничего под tags, только
создавать, и не позволял создавать тег, у которого был external, ссылающийся
на изменяемое состояние репозитория (т.е. ссылаться можно было либо на
какую-то конкретную ревизию, либо на тег другого репозитория).

И есть support branches - для исправления багов, найденных в выпущенных
релизах. Она форкается от соответствующего релиза, и дальше примерно как с
release branch, только тестировщиком порой работает клиент, у которого
обнаружилась и воспроизводится проблема - ибо не всегда удается воспроизвести
проблему у себя.

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

--
на вопрос как дела? отвечать 304 Not Modified
-- http://bash.org.ru/quote/20466

Re: Подскажите инструментарий для file release system.

11.10.2011 12:00, Artem Chuprina пишет:

Есть ствол, где идет основная разработка.

очень большой минус SVN в этом случае - куча конфликтов и надо будет вручную
копипастить изменения. В меркуриале как то все само сращивается молча.

Re: Подскажите инструментарий для file release system.

2011-10-11 Пенетрантность Konstantin Fadeyev

Есть ствол, где идет основная разработка.

Есть feature branches - для экспериментов с отдельными идеями, иногда
довольно
продвинутыми. Одна такая ветка жила два года. Но в норме идея в том, что
ты
форкаешь ветку, реализуешь фичу, прогоняешь ее через тестовую ферму (была
система автоматической сборки и прогона тестов), и либо в конце концов
решаешь, что идея была дурацкая и просто убиваешь ветку, либо вливаешь
результат в основную (если точнее, то технологически ты сначала вливаешь
пропущенные изменения из ствола в свою ветку, снова тестируешь, и только
потом
вливаешь результат в ствол).
очень большой минус SVN в этом случае - куча конфликтов и надо будет вручную
копипастить изменения. В меркуриале как то все само сращивается молча.

Уже года три-четыре как в SVN извели эту проблему. Там, правда, ключ
определенный надо сказать. В svn-book это описано.

--
А вы поподробнее, поподробнее. А заодно и быстрее будет...

Re: Подскажите инструментарий для file release system.

Я не программист, и по большому счёту проблемы разработки крупных
программных продуктов мне чьюжды.
Но уж если нужен контроль версий, безопасный доступ к файлам и
контроль прав доступа. На ум приходит git+ssh+selinux. Правда как это
увязать с задачами топик-стартера? Тем более учитывая такой зоопарк
платформ.
Ну предположим. Git держит кучу файлов в относительном порядке. Доступ
к хранилищу по ssh и сертификатам. Так, selinux палит пользователя и
его процессы, куда им можно и куда нет, и что им и там можно.
Есть у идеи шансы на жизнь?

-- 
Константин Фадеев

Re: Подскажите инструментарий для file release system.

2011-10-11 Пенетрантность Ivan Shmakov

 Konstantin Fadeyev jred...@gmail.com writes:

[…]

  Ну предположим.  Git держит кучу файлов в относительном порядке.
  Доступ к хранилищу по ssh и сертификатам.  Так, selinux палит
  пользователя и его процессы, куда им можно и куда нет, и что им и там
  можно.  Есть у идеи шансы на жизнь?

Полагаю, SELinux позволяет ограничить права на уровне файловой
системы — доступа к файлам и директориям.  Проблема в том, что с
точки зрения Git-хранилища, все изменения находятся в файлах с
именами вида .git/objects/SH/A-1.  Не думаю, что SELinux может
предотвратить вносение в хранилище objects/-файл с изменением
вида:

--- denied/file
+++ denied/file

в то же время дозволяя пользователю внести:

--- allowed/file
+++ allowed/file

Возвращаясь к теме, я, пожалуй, поддержу идею «анархии» как
подхода: будем считать каждого разработчика достаточно умным,
чтобы /не/ вносить изменения в те части кода, в которых его
вклад не приветствуется.

AIUI, Debian работает по такому принципу.  E. g., любой D-D
может загрузить новую версию любого пакета в incoming/, или же
управлять отчетами любого пакета в BTS.

-- 
FSF associate member #7257


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/86sjmz1j3s@gray.siamics.net

Re: Подскажите инструментарий для file release system.

2011-10-11 Пенетрантность Konstantin Fadeyev

12 октября 2011 г. 0:25 пользователь Ivan Shmakov
i...@gray.siamics.net написал:
Konstantin Fadeyev jred...@gmail.com writes:

[…]

Ну предположим. Git держит кучу файлов в относительном порядке.
Доступ к хранилищу по ssh и сертификатам. Так, selinux палит
пользователя и его процессы, куда им можно и куда нет, и что им и там
можно. Есть у идеи шансы на жизнь?

Полагаю, SELinux позволяет ограничить права на уровне файловой
системы — доступа к файлам и директориям. Проблема в том, что с
точки зрения Git-хранилища, все изменения находятся в файлах с
именами вида .git/objects/SH/A-1. Не думаю, что SELinux может
предотвратить вносение в хранилище objects/-файл с изменением
вида:

--- denied/file
+++ denied/file

в то же время дозволяя пользователю внести:

--- allowed/file
+++ allowed/file

Возвращаясь к теме, я, пожалуй, поддержу идею «анархии» как
подхода: будем считать каждого разработчика достаточно умным,
чтобы /не/ вносить изменения в те части кода, в которых его
вклад не приветствуется.

AIUI, Debian работает по такому принципу. E. g., любой D-D
может загрузить новую версию любого пакета в incoming/, или же
управлять отчетами любого пакета в BTS.

--
FSF associate member #7257

Пожалуй я уже совсем выхожу за рамки своих знаний. А если накладывать
ограничение selinux на сам git? Правила selinux достаточно гибки для
этого? Сделать комбинацию ограничений, на пользователя и на git.

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

--
Константин Фадеев

Re: Подскажите инструментарий для file release system.

2011-10-11 Пенетрантность Oleksandr Gavenko


11.10.2011 19:05, Artem Chuprina пишет:

Есть ствол, где идет основная разработка.


очень большой минус SVN в этом случае - куча конфликтов и надо будет вручную
копипастить изменения. В меркуриале как то все само сращивается молча.


Уже года три-четыре как в SVN извели эту проблему.  Там, правда, ключ
определенный надо сказать.  В svn-book это описано.


Это про лето 2010 и SVN 1.6 c svn:merge свойством, цепляемым на каталог
после использования команды svn merge?


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/j724jo$pqf$1...@dough.gmane.org

Re: Подскажите инструментарий для file release system.

2011-10-11 Пенетрантность Oleksandr Gavenko

11.10.2011 22:14, Oleksandr Gavenko пишет:

11.10.2011 19:05, Artem Chuprina пишет:

Есть ствол, где идет основная разработка.

очень большой минус SVN в этом случае - куча конфликтов и надо будет
вручную
копипастить изменения. В меркуриале как то все само сращивается молча.

Это про лето 2010 и SVN 1.6 c svn:merge свойством, цепляемым на каталог
после использования команды svn merge?

Вот что примечательно - механизм svn:merge предвосхищает возможности
всех популярных DVCS.

Всем известен механизм cherry-pick или transplant (как вам по душе
угодней называться) и почему это нужно (напомню - для распространения
баг фиксов по веткам).

Что же плохого в cherry-pick? Мы теряем историю мержей! Наши GIT/HG/BZR
базируються на DAG графе, а cherry-pick'ом мы плюем на этот граф.

В идеалах существующей архитектуры DVCS мы должны были бы сделать
следующее:

* bisect'ом найти первую ревизию BADREV, внесшую баг.
* Посмотреть на дерево бранчей и пометить те вершины, в
которых мы заинтересованы в исправлении бага BR1REV, BR2REV.
* Выполнить команду:

$ hg log -r ancestors(BADREV,BR1REV,BR2REV)
$ git-merge-base BADREV BR1REV BR2REV

и исправить баг в полученой ревизии.

Затем мы можем багфикс правоставно смержить (НЕ ЧЕРИПИКИТЬ!!) в
BR1REV, BR2REV, ...

Почему то люди отказываться от указаных шагов и фиксят баг на вершине
истории и распространяют исправление в виде патча с помошью вишенки...

C svn:merge вишенка была бы умной, но увы... куча конфликтов
гарантирована при частом обращении к вишенке.

Re: Подскажите инструментарий для file release system.

2011-10-11 Пенетрантность Oleksandr Gavenko


11.10.2011 22:37, Oleksandr Gavenko пишет:

$ hg log -r ancestors(BADREV,BR1REV,BR2REV)

Правильно делать:

  $ hg log -r 'ancestor(BADREV,ancestor(BR1REV,BR2REV))'


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/j7279h$bjm$1...@dough.gmane.org

Re: Подскажите инструментарий для file release system.

2011-10-11 Пенетрантность Ivan Shmakov

Oleksandr Gavenko gaven...@gmail.com writes:

[…]

Вот что примечательно - механизм svn:merge предвосхищает возможности
всех популярных DVCS.

Что же плохого в cherry-pick? Мы теряем историю мержей! Наши
GIT/HG/BZR базируються на DAG графе, а cherry-pick'ом мы плюем на
этот граф.

GNU Arch (tla(1)) не базируется на направленном ациклическом
графе. Что дает лучшую поддержку cherry-picking.

К сожалению, все прочие идеи, реализуемые GNU Arch
(использование системных diff(1), tar(1), etc. как основы для
формата хранилища; возможность ссылаться на историю изменений
вне хранилища; стандартизация формата имени ветки; etc.), себя
не оправдали.

[…]

--
FSF associate member #7257

Re: Подскажите инструментарий для file release system.

2011-10-10 Пенетрантность Dmitry Fedorov

10 октября 2011 г. 23:11 пользователь Oleksandr Gavenko написал:

Предприятие занимается разработкой ПО и имеет множество внутренних
библиотек/модулей, которые, для поддержания модульности, релизятся
(в настоящий момент) на FTP для возможности использовать
другими проектами.

Мерзкая мастдайщина и глупость.
Модули/библиотеки хотя бы внутри предприятия
должны быть доступны в исходных текстах
через систему управления версиями и собираться для каждого проекта.
Через неё же и управление доступом ro/rw к разным веткам, и файлам
для разных пользователей.

В моём случае это git и gitolite.
Надеюсь, все слышали, что kernel.org тоже переходит на gitolite?

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

gitolite умеет.

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

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

Re: Подскажите инструментарий для file release system.

2011-10-10 Пенетрантность Sergey Stremidlo

  Я также подумал об использовании SVN для хранения результатов сборки
  (в основном это бинарные файлы).
 
 Ещё одна мерзкая мастдайщина -- любые результаты сборки в репозитории
 исходных текстов - мусор.
 В репозитории исходных текстов должны храниться только исходные тексты
 - то есть, то, что набрано пальцами человека.
 Всё остальное - производное от них и создаётся автоматически.

Возражу.

Знает ли многоуважаемый дон, что такое действительно большой программный
комплекс и на скольких языках там бывают фрагменты?  И со скольки платформ?

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

Для примера, у меня сейчас идет работа на Haskell под Linux, и я использую три
сетевых протокола, две библиотеки и векторную карту.  Библиотеки в понимании
юних падаванов, в исходниках (C++), но фактически существенная половина одной
из них генерируется из проекта на Smalltalk (на котором проекты вообще в норме
живут не в виде исходников, а в виде виртуальной машины, и местами из этих
машин очень нетривиально вывалить дерево исходников, которое сможет
запуститься - хотя теоретически оно это умеет), а во вторую я заглядывал
только на уровне написать такой Makefile, чтобы из них собралась библиотека,
способная выполнить четыре нужных мне вызова.  Как и чем рисуют карту,
которую отображает эта библиотека, я вообще ни в зуб ногой, но кажется,
рабочая платформа тех, кто ее делает - MacOS X, и нет, они не портировали свой
софт больше никуда.

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

И накойхер мне от тех карт, того комплекса и того проекта на Smalltalk
исходники, если я на своем недобуке один фиг ничего с ними сделать не смогу?

-- 
Functional programming is like describing your problem to a
mathematician.  Imperative programming is like giving instructions to
an idiot.
 -- arcus, #scheme on Freenode


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/877h4cn5z4.wl%...@ran.pp.ru

Re: Подскажите инструментарий для file release system.

2011-10-10 Пенетрантность Dmitry Fedorov

10 октября 2011 г. 23:53 пользователь Artem Chuprina написал:

 Знает ли многоуважаемый дон, что такое действительно большой программный
 комплекс и на скольких языках там бывают фрагменты?  И со скольки платформ?

К счастью, нет.

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

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

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

Рабочее место - необязательно недобук, это может быть
аккаунт на большой машине, той самой стойке.

 из них генерируется из проекта на Smalltalk (на котором проекты вообще в норме
 живут не в виде исходников, а в виде виртуальной машины, и местами из этих
 машин очень нетривиально вывалить дерево исходников, которое сможет
 запуститься - хотя теоретически оно это умеет),

Плохо.
Как насчёт воспроизводимости?

Re: Подскажите инструментарий для file release system.

10.10.2011 20:29, Dmitry Fedorov пишет:

10 октября 2011 г. 23:11 пользователь Oleksandr Gavenko написал:

В моём случае это git и gitolite.
Надеюсь, все слышали, что kernel.org тоже переходит на gitolite?

gitolite умеет.

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

SVN помоему очень плохо, особенно для двоичных файлов.
я для маленького проекта использую Mercurial в котором находятся
исходники, скрипт и список.
Скрипт считывает список с адресами загружаемых файлов и собственно
загружает эти файлы с ftp.
Т.е. при маленьком репозитории в несколько мегабайт я получаю
возможность докачать всякие справочники и книги в формате pdf, программы
и прочее раздув рабочую папку под гигабайт.
Для больших проектом мне кажется надо сделать всетаки FTP с возможностью
создавать новые папки и файлы, но не перезаписывать существующие и
продумать систему нумерации версий, чтобы один отдел не порушил труды
другого внеся изменения в свои бинарники, которые стали работать чуть по
другому.

Re: Подскажите инструментарий для file release system.

2011-10-10 Пенетрантность Evgeny Kapun

10.10.2011 20:11, Oleksandr Gavenko пишет:
 Предприятие занимается разработкой ПО и имеет множество внутренних
 библиотек/модулей, которые, для поддержания модульности, релизятся
 (в настоящий момент) на FTP для возможности использовать
 другими проектами.
 
 С доступом на чтение все просто - анонимный доступ через FTP/HTTP, etc.
 
 А вот запись на FTP посредством прошитого логина/пароля в скрипт сборки
 совсем не нравиться...
 
 После гугления и вопросов на stackoverflow и comp.software.config-mgmt
 пришел к выводу что бы избавиться от хранения логина/пароля
 можно воспользоваться scp/sftp и открытыми ключами.
 
 Но как то мне не ясно каким образом разделять права на запись
 между различными проектами различным персонам...
 
 Не создавать же отдельную группу пользователей для каждого проекта и +s
 на корневой каталог?
 

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

 
 Я также подумал об использовании SVN для хранения результатов сборки
 (в основном это бинарные файлы).
 
 Мне кажется в этом случае получаем рад преимуществ:
 
  * синтаксис svn.authz интуитивно понятен, права описаны в одном
месте и очень компактно
  * аутентификация из существующего LDAP
  * пароли кешируються встроеным менеджером клиента SVN
 
 
 Имея опыт с FRS от sourceforge - скажу мне нравится, но изучать
 GForge с моим уровнем знаний будет сложно.
 
 Собственно резумируя - посоветуйте или пните в соответствующее
 направление по теме каким образом можно организовать релиз файлов
 на некоторый сервис с удобным разграничением доступа.
 
 


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e9333a0.9090...@gmail.com

Re: Подскажите инструментарий для file release system.

2011-10-10 Пенетрантность Иван Лох

On Mon, Oct 10, 2011 at 09:36:25PM +0400, Sergey Stremidlo wrote:
 исходники, скрипт и список.
 Скрипт считывает список с адресами загружаемых файлов и собственно
 загружает эти файлы с ftp.
 Т.е. при маленьком репозитории в несколько мегабайт я получаю
 возможность докачать всякие справочники и книги в формате pdf,
 программы и прочее раздув рабочую папку под гигабайт.

В git Для этого существует специальное расширение git-annex,
позволяющее эффективно хранить неизменяемые большие файлы,
прозрачно перемещая их, при необходимости, между репозитариями.
Удобная штука, кстати говоря.


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111010185442.gc27...@nano.ioffe.rssi.ru

Re: Подскажите инструментарий для file release system.

  Знает ли многоуважаемый дон, что такое действительно большой программный
  комплекс и на скольких языках там бывают фрагменты?  И со скольки платформ?
 
 К счастью, нет.
 
 Идея скрестить кита и слона, чтобы получить живого мамонта
 с горизонтальным хвостом не вызывает во мне энтузиазма.
 
 Если разработчики некой платформы не в состоянии
 отделить исходники от продукта этих самых исходников,
 то к такому продукту я и приближаться не хочу.

Сэр точно внимательно читал, прежде чем наехать?  Нормально там отделяются
исходники от продукта.

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

Рабочее место - не обязательно аккаунт на большой машине.  Зато рабочее место
разработчика обязательно НЕ на стойке, которая является частью результата
(хинт: результатом работы является не программа на пять килобайт пострипанного
бинарника, а программно-аппаратный комплекс на пол-ангара, включающий в себя,
помимо той стойки, еще десятка три embedded компьютеров различных архитектур и
энное количество аналоговой аппаратуры, а также некоторое количество тонн
металлоконструкций).

И потом, мне удобнее на недобуке.  На недобуке я могу работать в поезде и
прочих труднодоступных для связи местах.  Мне при практичном подходе этого
вполне достаточно, а бываю я в таких местах нередко.

Замена же практичного подхода на кошерный, как правило, резко негативно
сказывается на результате.

  из них генерируется из проекта на Smalltalk (на котором проекты вообще в 
  норме
  живут не в виде исходников, а в виде виртуальной машины, и местами из этих
  машин очень нетривиально вывалить дерево исходников, которое сможет
  запуститься - хотя теоретически оно это умеет),
 
 Плохо.
 Как насчёт воспроизводимости?

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

-- 
Пифагоровы штаны Лобачевскому смешны
 -- lj user=osd


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/8762jwmz7s.wl%...@ran.pp.ru

Re: Подскажите инструментарий для file release system.

С доступом на чтение все просто - анонимный доступ через FTP/HTTP, etc.

А вот запись на FTP посредством прошитого логина/пароля в скрипт сборки
совсем не нравиться...

После гугления и вопросов на stackoverflow и comp.software.config-mgmt
пришел к выводу что бы избавиться от хранения логина/пароля
можно воспользоваться scp/sftp и открытыми ключами.

Не создавать же отдельную группу пользователей для каждого проекта и +s
на корневой каталог?

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

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

--
Parentheses? What parentheses? I haven't noticed any parentheses
since my first month of Lisp programming. I like to ask people who
complain about parentheses in Lisp if they are bothered by all the
spaces between words in a newspaper...
-- Kenny Tilton

Re: Подскажите инструментарий для file release system.

 Предприятие занимается разработкой ПО и имеет множество внутренних
 библиотек/модулей, которые, для поддержания модульности, релизятся
 (в настоящий момент) на FTP для возможности использовать
 другими проектами.
 
 С доступом на чтение все просто - анонимный доступ через FTP/HTTP, etc.
 
 А вот запись на FTP посредством прошитого логина/пароля в скрипт сборки
 совсем не нравиться...
 
 После гугления и вопросов на stackoverflow и comp.software.config-mgmt
 пришел к выводу что бы избавиться от хранения логина/пароля
 можно воспользоваться scp/sftp и открытыми ключами.
 
 Но как то мне не ясно каким образом разделять права на запись
 между различными проектами различным персонам...
 
 Не создавать же отдельную группу пользователей для каждого проекта и +s
 на корневой каталог?

 
 Я также подумал об использовании SVN для хранения результатов сборки
 (в основном это бинарные файлы).
 
 Мне кажется в этом случае получаем рад преимуществ:
 
   * синтаксис svn.authz интуитивно понятен, права описаны в одном
 месте и очень компактно
   * аутентификация из существующего LDAP
   * пароли кешируються встроеным менеджером клиента SVN
 
 Собственно резумируя - посоветуйте или пните в соответствующее
 направление по теме каким образом можно организовать релиз файлов
 на некоторый сервис с удобным разграничением доступа.

В принципе, идея с Subversion достаточно грамотная.  Мне, однако, все время
лень настраивать HTTP-вариант, и я предпочитаю ssh.  Ну и кроме того, я сейчас
предпочитаю распределенные VCS, из которых, если хочется попроще, лучше брать
mercurial.  Из централизованных - да, я бы брал Subversion.

У нас предприятие было маленькое, и в итоге всё свелось к тому, что от
разграничения прав один геморрой, поэтому всё свелось к ssh и одной группе
разработчиков.  Маленькое - это полтора десятка человек, которым нужен этот
доступ, и примерно столько же проектов.  Практика показала, что почти в каждый
проект может потребоваться коммит почти от любого разработчика.  Поэтому
технические средства разграничения только мешали - в конце концов, не
трехлетние дети работали, интеллекта не коммититься куда не надо людям
хватало.

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

-- 
Functional programming is like describing your problem to a
mathematician.  Imperative programming is like giving instructions to
an idiot.
 -- arcus, #scheme on Freenode


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/8739f0mymd.wl%...@ran.pp.ru

Re: Подскажите инструментарий для file release system.

2011-10-10 Пенетрантность Иван Лох

On Mon, Oct 10, 2011 at 11:19:19PM +0400, Artem Chuprina wrote:
 Нормально насчет воспроизводимости.  Снапшоты этой виртуальной машины тоже
 хранятся под VCS.  Просто среди смоллтоковцев люди по большей части неплохо
 образованные, и их не шокирует идея, что исходники - это не обязательно текст
 на C и вообще не обязательно текст.  Они подумали головой, и эта виртуалка у

Хранить снапшоты под VCS, конечно можно, но толку то? 


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111010194947.gd27...@nano.ioffe.rssi.ru

Re: Подскажите инструментарий для file release system.

10.10.2011 19:29, Dmitry Fedorov пишет:

10 октября 2011 г. 23:11 пользователь Oleksandr Gavenko написал:

Мерзкая мастдайщина и глупость.
Модули/библиотеки хотя бы внутри предприятия
должны быть доступны в исходных текстах

Доступны...

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

В силу ограничений опыта части разработчиков и отсутствия ряда
tool-chains на индивидуальных раб. местах нет возможности проводить
сборки.

Например, технические причины:

* JNI для нет смысла собирать Java разработчику.
* некоторые файлы подписываються ключем, подтверженным VeriSign,
нельзя позволять безответственному человеку давать возможность
подписывать произвольные тексты...
* некоторые файлы собираються *только* на особых платформах (AIX,
zSeries), было дело на время IBM предоставляло доступ к серверам...
* некоторые среды разработки *платные* (embedded, разные немассовые
чипы) и в природе нет *свободных* альтернатив, лицензии ограничивают
число экземпляров.

В моём случае это git и gitolite.
Надеюсь, все слышали, что kernel.org тоже переходит на gitolite?

О gitolite ранее не слышал, думаю полезная вещь. Правда более тяготею
к Mercurial...

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

Не! Не рядом с иходными текстами, а совсем отдельно. Складывать файлы
по иерархии, на подобии:

/[vendor]/[product]/[version]/[platform]

Я ищу способ разграничения доступа к веткам

/[vendor]/[product]

SVN хранит метаинформацию о правах в файле svn.authz и историю
аворства/дат в репозитории.

В случае scp/sftp/ftp/rsync права доступа
могут моделироваться (правда не знаю как это организовать) обычными
UNIX правами доступа к файлам/каталогам и ctime.

Re: Подскажите инструментарий для file release system.


10.10.2011 22:49, Иван Лох пишет:

On Mon, Oct 10, 2011 at 11:19:19PM +0400, Artem Chuprina wrote:

Нормально насчет воспроизводимости.  Снапшоты этой виртуальной машины тоже
хранятся под VCS.  Просто среди смоллтоковцев люди по большей части неплохо
образованные, и их не шокирует идея, что исходники - это не обязательно текст
на C и вообще не обязательно текст.  Они подумали головой, и эта виртуалка у


Хранить снапшоты под VCS, конечно можно, но толку то?


Там есть информация кто и когда, может представлять интерес.

Можно конечно ложить рядом README, но потом тяжело рекурсивно
по иерархии пробегаться по этим README (которые доступны через
 NFS/FTP/HTTP) для выяснения гадил ли Вася в прошлем месяце
и где...


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/j6vmfh$6q2$1...@dough.gmane.org

Re: Подскажите инструментарий для file release system.

10.10.2011 20:36, Sergey Stremidlo пишет:

*не перезаписывать существующие* ОЧЕНЬ хорошая мысль.

По идее все что релизится не должно перезатираться.

QA отдел же находит ошибки в *конкретной* версии, если версия не
указывает на сущность - это плохо - нет воспроизводимости.

Правда это требование очень сильное, но если и его выполнить,
тогда у меня будет безупречная модель.

Кажется в SVN в хуке можно отличать ADD от CHANGED и тут же рубать.

И вроде для FTP сервера команда STOR перезаписывает файл...
с FTP такой цели не достичь.

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

Это продумно! [MAJOR].[MINOR].[REV] с семантикой как описано в libtool
документации для библиотек + с учетом материала:

http://www106.pair.com/rhp/parallel.html

Что то мне идея с SVN все больше нравиться:

* обеспечивается атомарность (в комите путь
/[vendor]/[product]/[version]/[platform] может создать только
один клиент, другой получит конфликт)
* хуками скорее всего можно исключить возможность
внесения модификаций в существующие файлы
* удобно настраивать права доступа
* аутентификация из существующего LDAP (с ssh нужно создавать
кучу UNIX групп и пользователей)
* файлы анонимно раздаються по HTTP
* сохраняется метаинформация о том кто и когда добавил

В принципе любая DVCS скорее также подойдет.

Кажись Red Bean'овцы хвастали в SVN book хорошей работой с бинарными
файлами. Оригинальный дизайн, з думкою про Вас. Попробую протестировать.
производительность.

Re: Подскажите инструментарий для file release system.