А в Ваших нетленных постах ему отведено вообще отрицательное количество параграфов.
И что дальше? Вы на вопрос ответьте, что взамен-то?

ЗЫ. Заметьте, оппоненты не говорят, что VCS есть панацея.


Плюсую, давно хотел ровно это же написать.

Ничего нового предложено не будет.
Особо упорствующим могу прочитать курс о вреде перехода на тотал командер с командной строки. )))

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

Дело не в том, что файл лежал в SVN. А в том, что было приказано вставлять сей файл в свои проекты и менять в этом файле даже замятую было нельзя, потому что его создал сам Гуру програмирования.



Вы невнимательно читали. Проблему выявил я и потратил 2 недели на доказательство того, из чего она проистекает.
А этот "молодец" создал эту проблему. Он запретил создавать описание интерфейсов внутри проекта утверждая, что если все будут компилировать один и тот же файл, то системы будут всегда стыковаться - это было одним из аргументов появления SVN на фирме. Оказалось что это совсем не так, а бывают разные компиляторы и, как тут говорилось - разные настройки компиляторов.

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



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

Если вы работаете за рубежом, а ваши русские "чайники" в России, и вам для контроля за интенсивностью их работы, объёмом и качеством кода нужен SVN, и вы будете их работу проверять в нём - то так им и скажите.

Утверждать, что программист это тот у кого стоит Visual Studio 2013.3+SVN, а все остальные чайники - непрофессионально.

К сожалению ветка выросла в флейм, который меня совсем не интересует.

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

Вопрос заключался только в том, что некоторые люди конкретно не понимают, как правильно работать с SVN, и на каких принципах она построена. Они не спрашивают "зачем нужна SVN?", а спрашивают "как работать с SVN? Куда мне ложить свои файлы? Как мне увидеть код, что ты написал и т.д". Вот и все. Ну не понимают они абстракции репозитария и все. Но это совсем не означает, что они не хотят работать с SVN.

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

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

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

Опять же, где Ваши предложения? Критику мы видим, а дальше-то что?



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

Распространяете документ, где простыми словами описываете базовые команды с минимумом параметров. Наример, для случая svn:

svn checkout
svn update

svn add
svn commit

svn delele

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

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

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

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

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

Ну так это я и есть, если не догадались.


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

Т.е. вот такой мануал: http://tortoisesvn.net/docs/release/Tortoi...N_ru/index.html вам прочитать, отфильтровать и распечатать не по силам?

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

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

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

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

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

Где держите хранилище для SVN?

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

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

После не очень радостного пользования распределенной Mercurial (TortoiseHg) хочу попробовать централизованную.
Не хочу работать в команде, с командой, под команду. Поэтому и распределять, выходит, нечего. Всё моё.
В отдельном каталоге хорошо и просто, но логично иметь доступ и из дома и с работы. Поэтому лучше бесплатный svn-хостинг.

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