LINUX.ORG.RU

[VCS][Хочется странного] спрятать файлы от других разработчиков

 ,


0

0

Hello, всемогущий all. Вопрос по VCS.

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

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

возможно ли это, как это (проще) сделать и что для этого лучше подходит (git или svn)?

пока придумал следующие варианты:
1) отделить бранч (devel) от головы, добавить все свои файлы, по завершении этапа 1 удалить ненужные файлы, слить в основную ветку (trunk)
2) отделить бранч (devel) от головы, добавить все свои файлы, по завершении этапа 1 идет банальный cp devel/* trunk/* + cd trunk + commit
3) для DVCS: то же самое что и 1 или 2, только отдельная копия репозитория вместо бранча. (насколько сложно потом перекидывать изменения??)
4) отдавать контент в зависимости от пользователя (реализовано ли это вообще где-нибудь??)
нежелательный 5) не парить мозг и завести потом новый репозиторий, а первый сохранить на память.

★★

У нас в конторе используется разделение для svn-а. Есть один репозиторий со скрытой (исходники) и доступной (собранные библиотеки) частями. Есть другой, общий, где библиотеки из первого получаются через svn:external. Разрулить доступ так можно, если использовать svn через апач, искать по настройке AuthzSVNAccessFile. Можно ли через svn:// протокол - не знаю.

vega
()

А в CVS можно тупо поставить UNIX права на файлы. Ну и использовать git-cvs если хочется нормально VCS.

rymis ★★
()

> возможно ли это,

Да, конечно.

как это (проще) сделать и что для этого лучше подходит (git или svn)?

Git, его же используют все реальные пацаны :)

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

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Это может быть помешанное на «безопасности» начальство, которое думает, что если разделить исходники между разработчиками, то «инновации» никто на сторону не утащит. Я сталкивался с таким.

Reset ★★★★★
()
Ответ на: комментарий от Reset

> Это может быть помешанное на «безопасности» начальство, которое думает, что если разделить исходники между разработчиками, то «инновации» никто на сторону не утащит.

ТС ни слова не сказал о секретности. Насколько я понял, он хочет защититься от шаловливых рук команды изначальных разработчиков. Хотя вот это:

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

...вообще странное требование.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

>вообще странное требование.
спасибо Кэп, теги как бы намекают)

xydo ★★
() автор топика
Ответ на: комментарий от tailgunner

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

xydo ★★
() автор топика
Ответ на: комментарий от xydo

>>> Надо сделать так, чтобы у других разработчиков не было доступа ни к ним, ни к истории изменений 1-го этапа.

вообще странное требование.

спасибо Кэп, теги как бы намекают)

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

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

хочу в любой момент на любой машине получить полную копию проекта со всем своими файлами.

И что? Любая DVCS дает тебе такую возможность. Даже соответствующим образом настроенная SVN дает ее.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

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

я задал вопрос, вы говорите: ответ знаю, но зачем он тебе? ну, ребячество, честное слово...

Любая DVCS дает тебе такую возможность

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

xydo ★★
() автор топика
Ответ на: комментарий от vega

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

rymis, да, cvs - вещь матерая, но права доступа проблемы не решат.

xydo ★★
() автор топика
Ответ на: комментарий от xydo

>> Конечнно, задача решается тривиально, но _зачем_?

я уже ответил выше.

Это не ответ.

что вам стоит написать одно предложение-суть решения задачи?

Ответы слишком уж тривиальны, поэтому я не уверен, что правильно понял задачу. Впрочем, изволь: при окончании этапа 1 делаешь экспорт последней версии, и импортируешь ее в репозиторий, доступ к кторому имеешь только ты. То есть у тебя будет репозиторий стадии 1, и репозиторий стадии 2. Если в первом сделают еще что-то полезное, опять импортируй новую версию (в общем, репозиторий стадии 1 используется как источник кода для vendor branch). Этот трюк сработает с любой VCS.

В случае Mercrial, Git и прочих достойных систем, при окончании стадии 2 просто сделай клон репозитория, и никого в него не пускай (преимущество DVCS - в том, что импорт изменений из репозитория 1 стадии делается проще).

я задал вопрос, вы говорите: ответ знаю, но зачем он тебе? ну, ребячество, честное слово...

А мне обычно приходится сталкиваться с вопросами, которые к сути дела не относятся, поэтому я стараюсь не отвечать, пока не пойму суть (или буду думать, что понял). Например, я не понимаю, что значит фраза:

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

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

Что, у на 1-м этапе в каталоге проекта лежат файлы, к которым не должно быть доступа (на чтение, на запись или как?)? Такое делается хуками и в SVN, и в Mercurial.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

на чтение, на запись или как?

если бы на чтение/запись, я бы явно это указал.

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

может надо было так?

Надо сделать так, чтобы на 2-ом этапе у других разработчиков не было доступа ни к ним, ни к истории изменений 1-го этапа.

но, имхо, это и так было очевидно (если внимательно читать)

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

PS: я не утвержал, что ответы должны быть нетривиальными)

xydo ★★
() автор топика
Ответ на: комментарий от tailgunner

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

xydo ★★
() автор топика
Ответ на: комментарий от xydo

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

Непонятно, зачем эти файлы вообще лежат в рабочем каталоге, если не каждый может «получить контент» (это означает права на чтение?); непонятно так же, что значит «получить контент авторизованным способом».

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

Изложено? Да. Всё? Тоже может быть. Но в качестве легкого троллинга, напомню классическое «Кто ясно мыслит, тот ясно излагает».

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

блин, если вы реально хотели бы помочь, но не поняли что-то, у вас бы возникли уточняющие вопросы, какие конкретно моменты непонятны. я их не увидел, кроме слов «ничего не понял и не собираюсь, ибо это никому не надо». ну и кто после этого тролль?

xydo ★★
() автор топика
Ответ на: комментарий от xydo

> блин, если вы реально хотели бы помочь, но не поняли что-то, у вас бы возникли уточняющие вопросы

Хм, а ты не заметил вопросов? Чтобы не перечислять их заново (ну типа что плохого в том, что все видят историю, зачем в рабочей копии нечитаемые файлы, как и зачем дается авторизация на их чтение), задам их все скопом: опиши свой use-case. Но не в стиле «вот вам то, что я считаю нужным реализовать, скажите как», а в стиле «вот передо мной задача ...».

кроме слов «ничего не понял и не собираюсь, ибо это никому не надо»

Кроме «ничего не понял», это всё плод твоей фантазии. А на самои деле мне интересно, что такое ты задумал.

и кто после этого тролль?

Если учесть, что я тебя в троллинге не обвинял, а в том, что сам троллю - признался, ответ очевиден :)

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Скажите, пожалуйста, господин xydo, а Вы не собираетесь разместить в разрабатываем Вами для кого-то проекте «бомбу», «скрытый вход для себя», «недокументированные свойства программы», «трояна» или что-то подобное, о чем не должены знать заказчик проекта и другие его исполнители?

Ничем другим я не могу объяснить столь «сверх странное» желание закрыть от всех все файлы (скрытые свойства) 1-го этапа проекта.

deg
()
Ответ на: комментарий от deg

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

желание закрыть от всех __все__ файлы

вот тут не надо выдумывать... я такого не говорил.))

xydo ★★
() автор топика
Ответ на: комментарий от tailgunner

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

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

зачем в рабочей копии нечитаемые файлы

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

как и зачем дается авторизация на их чтение

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

а в стиле «вот передо мной задача ...».

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

тем не менее, сейчас проверяю путь, указанный в 3.2 (см. первый пост), с 2-мя git-репозиториями. скорей всего мне этого будет достаточно. могу потом подробней описать здесь схему, на которой остановился...

xydo ★★
() автор топика
Ответ на: комментарий от xydo

[git]
похоже всё сводится к импорту бранча из другого репозитория (где эти личные файлы предварительно удалены) с опустевшей историей.
[/git]

xydo ★★
() автор топика
Ответ на: комментарий от xydo

>>зачем в рабочей копии нечитаемые файлы

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

Да?

Однако в директории с проектом есть файлы [...] чтобы у других разработчиков не было доступа ни к ним

...это к вопросу о ясном изложении :)

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

*shrug* Давно уже сказано.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

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

Давно уже сказано.

вот уж не надо! про чистку истории никто еще не говорил.

xydo ★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.