Смешной вопрос! Конечно же пишите объяснительную записку в "лист регистрации изменений" вместе с заявлением об увольнении.

merge рабочей копии с версией такой-то (можно выбрать по логу, например) и интерактивное выбирание нужных кусков (edit conflict). Затем коммит новой рабочей копии.

Нажмите для просмотра прикрепленного файла

Легко и небрежно.

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

P.S. пошел качать последнюю TortoiseHg

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

Типа начальник думал, что никто не умеет извлечь нормальную версию. Оказалось не так, но СВН все равно виновата, ведь с нее же поначалу начались разборки. Аргумент убийственный, ничего не скажешь.
Да и начальник, если задуматься, не особо и дурак-то...


На деле еще легче. Часто конфликтов гораздо меньше и изменения вносятся автоматом.

Для информации, SlickEdit делает merge и diff между любыми файлами, а не только теми которые были вставлены в проект репозитария.
А Total Commander делает сравнение по содержимому даже в архивах и даже в архивах архивов.



Я вижу вы не поняли. Как я сказал в самом начале исходники ничто без средств разработки. И это был яркий пример.
Я скажу что даже с одним и тем же средством разработки вы получите аналогичный убийственный результат просто слегка изменив настройку того средства разработки.
А теперь давайте-ка проиндексируйте каким нибудь SVN-ом этак всю директорию IDE.
Особенно меня порадует картина когда проиндексируете Embarcadero или MS SQL.

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

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

diff/merge из комплекта ЧерепахаSVN такой же. Не вносите смуту.



Это реально мало интересует. Все вопросы по архивации (в смысле упаковки/распаковки) от конечного пользователя в SVN спрятаны.

А версию такую-то нужно сначала вытащить на свет из недр диф-архива? Сделать ее актуальной, или как оно там называется?

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



Неясна связь аж вообще.



А другие вынужденно привязываются к упомянутому Total Commander'у, чем дальше - тем сильнее



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



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

Храню полные имиджы дисков VMware со всей инфраструктурой.
SVN нервно курит.




Total это то без чего на компе вообще делать нечего. Это все равно что привязаться к PC.




Значит очень редко создаете проекты.

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

но тут народ жжёт не по детйки )) ржал долго...

Не надо путать создание очередного проекта в репозитории (что есть два клика) и администрирование самой системы контроля версий - сервер и так далее (что мне пришлось за 10 лет проделать ровно три раза, последний раз - года четыре назад, аптайм там, кстати, такого же порядка).



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

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

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

тотал получше, но осадочек остался ))

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

ааааааааааа!!!!
+100500

ржу. пац талом


мужики ну животик уже болит блин! кончай стёб

Да вот не совсем яркий пример-то. И исходники - не есть ничто. Но даже не в этом дело, а в том, что Вы этот пример пытаетесь использовать, чтобы показать, что контроль версий не нужен. И у Вас это не получается.
Система не контролирует то, что в ней не лежит, и во многих мануалах к разным системам прямо так и написано. Чтобы кое-кто не думал, что она их спасет от всех косяков наподобие того, что было в примере про пакеты езернета. Не умеете применять компилятор - ваши проблемы, исходники-то тут причем? И (как производная) - контроль версий тут причем? А начальник молодец. Не дал создать несколько разных исходников, выявил причину проблемы и спас тем самым много часов на поиски этой же проблемы в будущем. Никто бы не узнал, что один и тот же исходник может приводить к разным эффектам на разных ОС, если бы не этот начальник. И этот косяк (при должном стечении обстоятельств, а обычно оно случается) мог бы пролезть гораздо дальше по цепочке от начала разработки. Некоторые косяки вылезали уже только в процессе полета космических кораблей, и влекли за собой разрушение этих кораблей (помню похожую историю читал про шаттл, емнип).
Не причем тут контроль версий.

Что это за два волшебных клика? Можно детализировать?

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

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

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

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




Ай папки, так где ж тут два клика, тут барабанить надо будь здоров.
Вот в Total действительно два клика и архив готов.

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


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

Мы, похоже, один и тот же случай с ракетой вспомнили. Только с разных сторон.
Уж не хотите ли Вы сказать, что катастрофа в итоге была из-за негодности инструментов? С такими подходами, если бы Вы стали автором ариан-6, то он бы столь же неотвратимо грохнулся бы.
почитайте:
http://forums.airbase.ru/2013/10/t54337--a...shibk.6977.html


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

Стесняюсь спросить, а под какую версию тулчайнов были написаны lwIP, FreeRTOS, Linux и eCos? И не подскажете, где бы мне взять виртуалочку к каждому из перечисленных кодов, ну или архивчики lwIP_100%_worked(2)_10.05.2014.rar, FreeRTOS_not_worked_12.12.2012.rar? Кстати, объясните пожалуйста, а зачем любители архивов, типа вас, добавляют в имена слово worked?


А чем был заморочен народ в проект Фобос-Грунт? Архивчик перепутали?

важнее другое - а происходит ли массовое переименование всех старых архивов из _worked_ в _buggy_ при обнаружении ошибок?

или появляется новый с приставкой _worked_better_ ?

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

Ну из перечисленного у меня есть только полный рабочий имидж среды разработки uCLinux с BSP под stm32f4discovery и есть отдельный имидж Linuх для i.MX, есть имидж Win CE для i.MХ
Остальное из перечисленного не стоит внимания, поверьте.
И знаете почему? Да вот именно по тому что авторы на счет своих технологий помалкивают. А иначе они бы стали никому не нужны. А так всегда есть поле для платной подписки не тех. поддержку.

А что кто-то добавляет слово "100%_worked" ?
Забавно. Это конечно сознательное введение в заблуждение. Пректы такого уровня никогда не могут быть "100%_worked"

К сожалению нет. Накапливаются файлы типа:


Это в случае если человек сгенерил 3 рабочих версии за день. А очень часто любят еще и даты не ставить:




Конечно. Как архив назовешь, так он и поплывет. Я когда-то устраиваясь на работу, разгребал архивы предыдущих разработчиков, видел там 100%_worked и т.п.

А вот это правильно. Даты не надо ставить в названии архива. У каждого файла внутри и так есть дата.
И вообще сравнивать надо не по дате , а по содержанию.
Я если делаю архивы просто их последовательно нумерую.
Никаких объяснений и комментариев.
Если разработчик уж лезет в архив он должен его сравнить тотально с текущей версией, не веря и не обращая внимания ни на какие коменты к релизу.

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

В архивах нет веток. Архивы это этапы, чаше всего ненужные , а просто несущие функцию backup-а.
Понятие 'ветка' у меня не существует.

Абсолютно верно! Без VCS хардкор - единственно правильный стиль работы.
Если есть VCS, то можно спокойно обратить внимание на коменты к релизу. И каждый раз тотально сравнивать (освежая в голове контексты) ничего не надо будет. Не все, знаете ли, балдеют от такой работы.
Не стоит бояться, что мозги засохнут, если не будут постоянно все "разрабатывать с нуля".

Хотя... Если из примера про ариан-5 Вы сделали вывод, что реюз уже сам по себе - зло, а VCS - естественный спутник зла... Что тут сказать? А, вот что: у Вас есть уверенность, что без VCS Ваша команда смогла бы написать софт для ариан-5 без ошибки? Другими словами, вот Вы тут критикуете упорно, а сами-то взамен можете что-то предложить?

Ну что вам сказать, есть такой фундаментальный труд, называется "Совершенный код" С.Макконнелл
Считается библией программистов. 893 листа (считая обложку)
Вы не поверите, но там контролю версий выделено всего два маленьких параграфа!
Хотя охвачено все, от выбора метафор, чтоб программистам не было скучно и принципов объектного программирования до выбора имен переменных и количества отступов в текстах.
Вот такое место занимает VCS объективно в проблеме качества кода.

юмор набирал обороты...

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

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

по поводу именований, оформлении и иже - то вообще то требования кодинг рулеса и в каждой конторке своё как правило...

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

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

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

Да что вы в самом деле! Если все автоматизировать, то кто же тогда работать будет? Контроль и формализация? За слово "контроль" вас вообще здесь побьют, причем возможно по лицу :-)

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

ЗЫ. Заметьте, оппоненты не говорят, что 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-хостинг.

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