Привет всем! Чем более интересных и сложных проектов идеи возникают в голове, тем актуальнее становится вопрос: как обезопаситься от сливания всего исходного кода куда то "на сторону" кем-либо из команды разработчиков... Грубо говоря инвестор вкладывает кучу денег в разработку программного продукта, группа программистов над ним полгода трудится, и вдруг, некий программист Василий все сорсы из репозитория берёт и использует в личных целях (продаёт или "кидает" команду каким-либо другим образом). Я рад за тех, с кем такое не случалось и, надеюсь, что и мне не придётся сталкиваться, но известны случаи, когда так сливались проекты масштаба 10^6$.
Поэтому есть такая идея - разделить доступ к сорсам...
В общем постановка задачи...
Есть классы (сорсы) A, B, C, D, E
Есть программисты Петя, Саша, Маша
Петя работает над классом A, для разработки ему необходим доступ к классам B и C
Саша работает над классом C, для разработки ему необходим доступ к классам B, D и E
Маша работает над классами D и E
Соотв. нужно так организовать репозиторий, чтобы:
Петя имел доступ к A, B, C
Саша имел доступ к B, C, D, E
Маша имела доступ к D, E
при этом, ни один из разработчиков не имел бы доступ ко всем сорсам в целом.

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

Вообще небольшой оффтопик - поделитесь пожалуйста, если есть у кого-нибудь ссылки на хорошие статьи (желательно на русском, но можно и на англ, если там хорошо описано)), чтоб разобраться во всех штуках этого SVN - merge, branch, tag, patch...

Тут же встаёт вопрос о тестировании... Дома обычно так - скомпилил, протестил, работает - хорошо, не работает - ищешь баг, поправил, скомпилил, протестил....
Здесь вижу некий компилятор на стороне сервера (реализуемо для Java, PHP, Flex, думаю что для С++ тоже и много чего ещё))

Теперь ещё больший оффтопик - как организовывать непосредственно тестирование...
Хорошо, если баг сходу проявляется одним нажатием мышки на кнопку...)
А если это некий многопользовательский замут, и баг не так то просто воспроизвести... Ну к примеру запишем мы дебаг инфу - на какой строчке в каком файле... Программист начнёт там править, но ведь не все такие папки/профи, чтобы исправлять баги с первого раза, мне, например, иногда нужно несколько раз внести правки и протестить, а иногда и полдня чтобы найти и исправить ошибку в логике....
В общем подскажите кто знает, в какую сторону копать... Столько названий и технологий, что сходу и не понять с чего начинать..) Ну и хотелось бы статей, где люди описывают решения...)

Что есть tags прочитал где то в соседней ветке...
Что есть merge всё равно раздуплить не удалось - там какие то странные схемки...))

в смысле от хороших и известных журналистов издания "Коммерсантъ" (или National Geographic) ?
есть документация, причем переведенная на многие славянские языки, напр. на русский.

просто противно слушать.
Такие вещи "вдруг" не происходят: у разработчика, который подписывает нормальный контракт, и соглашение о неразглашении коммерческой тайны и т.д. такое не должно происходить. а если оно таки ДА происходит, это значит несколько вещей произошли одновременно (со стороны фирмы):
1) фирма-работодатель разработчика не протестировала на такого рода потенциал. сэкономили при найме, платите за это позже
2) фирма-работодатель платит низкую з/п относительно рынка, сэкономили на текущих расходах, платите за это позже.
3) фирма-работодатель не обращает внимание на настроение работников и их состояние духа, сэкономили на релаксах и хорошем руководсвте, платите позже.
4) фирма работодатель не вызывает у работника никаких положительных эмоций, и удар по ее экономическому статусу, а с ним и другим работника, коллегам, теоритически друзьям потенциального преступника, - значит насолили такому работники конкретно, пытались отыметь при увольнении (сэкономить на компенсациях, недоплата бенефитов разных, страховок, пенсионных фондов и т.д.), платите позже.
5) процесс кражи без несанцкионированного выноса информации наружу сделать нельзя: если экономим на безопасности информации (разрешаем вынос данных, удаленный доступ),  без инструктажа политики безопасности, и др. проактивных мер детекции потенциальных воров, а также обучении персонала - сэкономили, заплатите позже.

А все эти разделения, это все как банки мертвецу. Было бы желание, а взломать защиту можно всегда.
что самое интересное, при раскладе расходов, обычно все пункты хороших условий берутся в счет и презентуются вкладчику VP, однако нередко всякие князьки тырят эти вложения, обворовывая своих работников, и увеличивая свои з/п. Что можно сказать в таком случае?
правильно, жадный ЗАПЛАТИТ, и не единожды.

Конечно же существует и такой вариант: вор - индустриальный шпик, который получает не з/п а гонорар,
но в таком случае вопрос о характере продукта.
допустим вы своровали  код написанный на перле, и реализующий какую-то систему по управлению контентом.
на перле обычно пишется всё по методу "write-only code" (типа код только для написания, а не для чтения), и потом этот код надо поддерживать (читать, расширять). при проекте достаточной сложности, (напр. на несколько >6 нулей справа от самой правой цифры) это туева хуча кода, который надо расширять.
И на только понимание реализации уйдет время соразмерное с разработкой продукта самому.
И причем этот перл потом надо где-то хранить, и кому, кроме прямого заказчика нужен этот продукт ?
A потом, после предъявления обвинений нужно будет еще и объяснить в судe на кой черт были написаны строки 10-14 в файле xz.pl.
и на перле это не факт что вообще может ответить кто-то кроме автора.

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

Добавлено через 3 минуты и 57 секунд

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


Это сообщение отредактировал(а) bilbobagginz - 10.7.2011, 19:55

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


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


Полный бред - это не читая отвечать. Я писал в 1м сообщение, что в этом случае, ясен пень, надо предусматривать компиляцию проекта на стороне сервера. Т.е. каждый разработчик будет иметь доступ к скомпиленной программе, но не к её коду.
А она ему расскажет по скайпу весь свой исходный код, а потом они скооперируются с Сашей и тот тоже им расскажет свой исходный код, и так все 10-20-30-100 программеров проекта соберутся и кинут своего работодателя....)) БРЕД))   

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


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


Теперь вопрос совсем конкретный...
Народ, кто знает, подскажите плиз серверную софтину SVN/CVS или любую другую, где можно было бы разграничить права доступа?
Насчёт того, как компилить, думаю что можно сделать просто отдельный скрипт, запускающий команду из шела)

Это сообщение отредактировал(а) nucer - 13.7.2011, 08:13

Зачем какая-то софтина, если на самом сервере SVN можно указать права, вплоть до последнего файла в дереве проекта?

nucer, 

это делают недоплаченные.

это делают недоплатившие. а доплатившие еще и адвокатам платят. 
(кстати, в России уже были прецеденты осуждения за кражу интеллектуальной собственности)

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

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

Если вы вложите слишком много веса в безопасность, то такие организационные болезни как:

• задержки передачи информации (тормоза)
• дубляж усилий (ненужные расходы)

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

удачи.

Добавлено через 3 минуты

кстати тут самый опасный - Саша, a потом нужно как-то подкатить к Пете с просьбой о помощи с A.



Это сообщение отредактировал(а) bilbobagginz - 16.7.2011, 20:29