QNX.ORG.RU

Общее => Общение => Тема начата: da-nie от Июня 24, 2017, 07:29:07 pm



Название: Система контроля версий Git
Отправлено: da-nie от Июня 24, 2017, 07:29:07 pm
Как это ни странно, но я никогда не работал с системами контроля версий. Ну просто я не программист и не инженер-программист, а просто инженер, хотя и 80% времени я занимаюсь именно разработкой и сопровождением ПО стендового оборудования, ПО систем, ПО обработки данных и 20% электроникой. И в моей конторе для ПО ничего подобного не применяется. Да и программы пишут 1-2 человека, не более. Максимум, что по ПО очень хочет руководство, так это класть в архив (у нас применяется система Windchill ) бредовые документы типа "Методики тестирования ПО" и оформление всяких "Руководство оператора" и "Описание программы". В целом, обычный ГОСТ на ЕСПД, устаревший в прошлом веке (поверите ли, до 2014 мы прикладывали к исходникам в архиве файл, где писали, что кодировка в программе КОИ-8 - того требовали  внутренние документы предприятия, основанные на лохматом ГОСТ'е. Конечно, кодировка была совсем другая. :) Но файл обязан был быть.). Собственно, решил я попробовать систему GIT. И сразу появились вопросы, которые книжка, если и описывает, то, наверное, где-то ближе к концу.
А вопросы вот какие:
1) Если мы с гипотетическим Васей пишем программу вместе и Вася решил добавить в интерфейс новую кнопку, он меняет некий файл, где добавляет новый функционал. А в это время я тоже решил сделать другую кнопку и в том же файле у себя тоже пишу свой функционал. Как нам слить функционалы вместе? :o Это разве не две разные ветки программы получатся? Или система контроля версий обладает ИИ и способна понять, как объединить совершенно разный код? Этот вопрос родился из того, что я не понимаю, как на GitHub разные люди тянут программу каждый в свою сторону (с Васей-то мы договоримся менять только свои части.).
2) Тот же вопрос, только Вася взял и удалил некоторые классы. А я на своей копии (которую я сделал по git clone) с ними работаю. Возвращаю их обратно в репозиторий (git add) и... бардак в репозитории?

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

Спасибо. :)


Название: Re: Система контроля версий Git
Отправлено: darkelf от Июня 26, 2017, 12:59:35 pm
К сожалению по Git подсказать не могу, у нас используется Subversion так-же известный как svn. Они, в принципе, похожи, но в многих практических вопросах могут отличаться, так-что я не уверен, насколько опыт работы с svn может быть применим к Git.


Название: Re: Система контроля версий Git
Отправлено: da-nie от Июня 26, 2017, 04:49:47 pm
А как в subversion подобные вопросы решаются? :) Суть-то у всех этих систем одна и та же.


Название: Re: Система контроля версий Git
Отправлено: darkelf от Июня 26, 2017, 05:55:58 pm
А как в subversion подобные вопросы решаются? :) Суть-то у всех этих систем одна и та же.
Хорошо решаются.

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


Название: Re: Система контроля версий Git
Отправлено: lastcross от Июня 26, 2017, 06:59:55 pm
Если Вы с гипотетическим Васей редактировали разные файлы или даже один и тот-же файл, но в разных, не пересекающихся местах, то система контроля версий автоматически объединит Ваши изменения.

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

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


Название: Re: Система контроля версий Git
Отправлено: da-nie от Июня 26, 2017, 07:05:16 pm
Цитировать
Вам система контроля версий не даст записать свои локальные изменения из рабочей копии пока Вы не обновите её до того, что есть в репозитории.
...
Если Вы редактировали одно и то же место, то svn даст возможность выбрать или Вашу правку, или Васину, или вообще написать свой вариант.

Занятно. 8) То есть, если Вася стёр тот фрагмент, который есть у меня, то система предложит варианты слияния? А что является единицей "места"? Вот в формуле Вася вписал знак минус, а я у себя поменял в этой же формуле имя коэффициента. Это одно и то же место или разные? Как они делятся?

Цитировать
При не пересечении кода - контроль версий не увидит конфликтов, но результирующий последний коммит без правок - не скомпилируется

Понятно. Значит, формально требуется координатор. Иначе мы с Васей разорвём программу на лоскуты.


Название: Re: Система контроля версий Git
Отправлено: lastcross от Июня 26, 2017, 08:05:50 pm
Занятно. 8) То есть, если Вася стёр тот фрагмент, который есть у меня, то система предложит варианты слияния? А что является единицей "места"? Вот в формуле Вася вписал знак минус, а я у себя поменял в этой же формуле имя коэффициента. Это одно и то же место или разные? Как они делятся?
Ну очевидно же, один из простых вариантов (для большинства текстовых файлов) - это пересечение в позиции (по строчной или даже посимвольной - от начал файла). Если одни изменения пересекаются с изменениями другого по позиции - значит автоматически система не сможет сама решить конфликт, она делегирует это решение последнему из (кто внес изменения и получил конфликт). Как он будет решать этот кофликт (в чью пользу) - это уже организационный момент и лежит вне GIT-компетенции ))

Цитировать
Понятно. Значит, формально требуется координатор. Иначе мы с Васей разорвём программу на лоскуты.

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


Название: Re: Система контроля версий Git
Отправлено: da-nie от Июня 26, 2017, 08:43:24 pm
Цитировать
Ну очевидно же, один из простых вариантов (для большинства текстовых файлов)

Я почему спрашиваю, есть всякие сравниватели файлов типа Beyond Compare. Там сравнение несколько сложнее и фрагменты разыскивает весьма эффективно (даже если их переставили местами).
А в моём примере с формулой мы с Васей не пересеклись по координатам символов. Следовательно, я так понимаю, что в формуле поменяется и знак (от Васи) и имя коэффициента (от меня). Прикольно будет, если это окажется ошибочная формула. :) Помнится, из-за ошибки в формуле (руководство было уверено, что это уже реализовано, но нет) в Роскосмосе была авария аппарата (уже не помню, какого). И кого-то там посадили за это.  ::)


Название: Re: Система контроля версий Git
Отправлено: darkelf от Июня 26, 2017, 09:25:49 pm
А в моём примере с формулой мы с Васей не пересеклись по координатам символов. Следовательно, я так понимаю, что в формуле поменяется и знак (от Васи) и имя коэффициента (от меня).
В svn сравнение идёт строками, так-что такой вариант Вам не грозит.


Название: Re: Система контроля версий Git
Отправлено: ob1 от Июня 27, 2017, 11:10:54 am
Что мешает взять Git в лапки и смоделировать все неясные моменты?


Название: Re: Система контроля версий Git
Отправлено: da-nie от Июня 27, 2017, 12:02:20 pm
Цитировать
Что мешает взять Git в лапки и смоделировать все неясные моменты?

Командная строка. :) И отсутствие опыта работы с такими системами. Вот взял я книжку "Pro Git". Автор сразу работает с удалённым репозиторием - сделайте, говорит, git clone. А у меня-то локальная машина. Также автор почему-то не раскрыл тайну, как добавить каждый проект в git - пишет, наберите git init. Набрал. И что? Ну тут мне хоть рассказали, что git init нужно делать внутри каждого проекта. Ну и так далее.


Название: Re: Система контроля версий Git
Отправлено: lastcross от Июня 27, 2017, 12:47:47 pm
Вот взял я книжку "Pro Git". Автор сразу работает с удалённым репозиторием - сделайте, говорит, git clone. А у меня-то локальная машина.
Разве? (https://git-scm.com/book/ru/v1/%D0%9E%D1%81%D0%BD%D0%BE%D0%B2%D1%8B-Git-%D0%A1%D0%BE%D0%B7%D0%B4%D0%B0%D0%BD%D0%B8%D0%B5-Git-%D1%80%D0%B5%D0%BF%D0%BE%D0%B7%D0%B8%D1%82%D0%BE%D1%80%D0%B8%D1%8F) Первый же пункт - "Создание Git-репозитория" вполне все хорошо объясняется.


Название: Re: Система контроля версий Git
Отправлено: da-nie от Июня 27, 2017, 01:34:22 pm
На самом деле, из первой же главы вообще не понятно, как разделять проекты и как добавлять файлы. Там просто не написано этого.
Цитировать
Если вы хотите добавить под версионный контроль существующие файлы (в отличие от пустого каталога), вам стоит проиндексировать эти файлы и осуществить первую фиксацию изменений. Осуществить это вы можете с помощью нескольких команд git add указывающих индексируемые файлы, а затем commit:
Делаем git add - а add чего? Где git возьмёт файлы? Не написано. К тому же оказалось, что файлы должны быть в каталоге git - иначе он их не видит, даже если перейти в выбранный внешний каталог.


Название: Re: Система контроля версий Git
Отправлено: lastcross от Июня 27, 2017, 05:58:14 pm
На самом деле, из первой же главы вообще не понятно, как разделять проекты и как добавлять файлы. ...
Делаем git add - а add чего? Где git возьмёт файлы? Не написано. К тому же оказалось, что файлы должны быть в каталоге git - иначе он их не видит, даже если перейти в выбранный внешний каталог.
Странно, но у меня вопросов не возникло (возможно по причине используемых ранее других контроль-версионных продуктов). Как бы было очевидно - контроль версий не имеет понятия ни о каком "проекте" (какому бы этот проект языку не относился или как бы не конфигурировался). Контроль версий работают с файлами в первую очередь. Ведь под их контролем может быть не только проект, а и набор несвязанных ресурсов/документов и тд. Другими словами - очевидно что под понятием "проектный каталог" имелся ввиду верхнего уровня каталог, в котором (и в подкаталогах которого) будут находится файлы которые и собираетесь поместить в репозиторий (дерево индексации). Как минимум это умолчательное поведение. И как правило оно же и накладывает отпечаток на формирование структуры каталогов в проектах.
Ну а дальше:

1) Ваша работа с git - это периодическое изменение, переиндексация состояния репозитория. Первичная индексация - git init, которая заставит его сформировать пустое дерево индексации начиная с указаного каталога (от имени которого вы выполнили эту команду)
2) Команды git add - заставят переиндексировать его состояние. У этой команды есть куча аргументов, но есть и такие которые укажут какие именно файлы нужно "добавить" (попытаться проиндексировать) или же сделать индексацию по всему дереву (от каталога и подкаталогов). Если окажется что состояние не изменилось (все файлы уже есть в репозитории или же не менялись и т.д.) - то переиндексации не будет. Если найдутся - он уведомит и сделает прериндексацию изменив состояние репозитория.


Название: Re: Система контроля версий Git
Отправлено: da-nie от Июня 27, 2017, 08:08:53 pm
Цитировать
Контроль версий работают с файлами в первую очередь.

Верно. Но просто файловая помойка неудобна. Если я потом сделаю clone, он мне отправит весь мой каталог разработки, а это примерно 4 ГБайта. И я такому клонированию не обрадуюсь. :) Поэтому первый же вопрос появляется, как разграничить проекты. Но автор книжки про этот вопрос забыл. Кстати,я так и не понял, могу ли я на локальной машине (т.е. не используя URL) клонировать репозиторий или нет? Типа git clone myproject.git.  Вроде бы нет - нужно поднимать сервер. И я также не понял, откуда берётся этот файл с расширением .git в репозитории (например, в сетевом). Изначально-то его нет в каталогах git, даже с созданным и инициализированным проектом. Но, возможно, я просто ещё не дочитал до нужного места.

Цитировать
Если найдутся - он уведомит и сделает прериндексацию изменив состояние репозитория.

Да. Но вот чтобы понять, как наши с Васей правки будут конфликтовать, придётся с консолью разбираться основательно. Надо попробовать поставить графическую оболочку. С git у меня ещё проблема одна - ему в текущей версии минимум Vista нужна. А у меня XP и обновлять я не планирую. Portable-версия запускается, но частенько не находит нужного в штатных dll Windows XP (что-то там с функцией синхронизации чего-то выскакивает). Но вроде как всё равно работает.


Название: Re: Система контроля версий Git
Отправлено: lastcross от Июня 27, 2017, 11:46:27 pm
Верно. Но просто файловая помойка неудобна. Если я потом сделаю clone, он мне отправит весь мой каталог разработки, а это примерно 4 ГБайта.
Откуда у вас 4GB исходников на проекте?
Как правило все файлы проекта делят на части.
Папка с исходниками библиотеки которые используются в проекте (и возможно не только в текущем).
Папка с собранными библиотеками
Папка с исходниками собственно проекта (только исходники, фалы-проекта, ресурсы и все что необходимо для нормальной компиляции проекта) - никаких объектников или временно-созданых фалов (отладочной инфы), никаких построенных экзешников там быть не должно
Папка с внешними ресурсами используемые проектом (при условии, что они могут изменятся независимо от исходников проекта) - конфиги разного характера, текстуры и т.д.
И т.д.

Так вот  - каждая из этих папок может быть как отдельным репозиторием, так и одним. Папки могут находится или рядом или в разных местах. Но я не вижу откуда у вас на двоих для одного проекта возьмутся 4 гига исходников.

Цитировать
И я такому клонированию не обрадуюсь. :)
По мере увеличения комитов - репозиторий будет увеличиваться. Так что клонирование со временем Вас все равно не будет радовать)

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

Цитировать
Кстати,я так и не понял, могу ли я на локальной машине (т.е. не используя URL) клонировать репозиторий или нет? Типа git clone myproject.git.  Вроде бы нет - нужно поднимать сервер. И я также не понял, откуда берётся этот файл с расширением .git в репозитории (например, в сетевом). Изначально-то его нет в каталогах git, даже с созданным и инициализированным проектом. Но, возможно, я просто ещё не дочитал до нужного места.
Так и есть, не дочитали.
Для гита не нужен отдельный сервер. Он является распределенной системой - то есть содержит как клиент так и сервер сразу. И ничего не мешает вам зайди в другую папку, и написать там git clone указав следующий параметр файловый/сетевой путь к папке которая является репозиторием (т.е. под гитом)

Цитировать

Да. Но вот чтобы понять, как наши с Васей правки будут конфликтовать, придётся с консолью разбираться основательно. Надо попробовать поставить графическую оболочку. С git у меня ещё проблема одна - ему в текущей версии минимум Vista нужна. А у меня XP и обновлять я не планирую. Portable-версия запускается, но частенько не находит нужного в штатных dll Windows XP (что-то там с функцией синхронизации чего-то выскакивает). Но вроде как всё равно работает.

Зато у вас WindowsXP. =)


Название: Re: Система контроля версий Git
Отправлено: da-nie от Июня 28, 2017, 08:48:39 am
Цитировать
Откуда у вас 4GB исходников на проекте?

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

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

Я тоже не про язык. Я про инкапсуляцию данных.
Кстати, интересно, как git справится со слиянием изменений при одновременной правке файла, например, типа doc. Думаю, что никак.

Цитировать
Так и есть, не дочитали.

Ну, я меня он ругается, что не может прочесть проект:

Цитировать
D:\GIT\1>git clone d:\GIT\Project\TestOrtohonalization.git

Cloning into 'TestOrtohonalization'...
fatal: Could not read from remote repository.

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


Название: Re: Система контроля версий Git
Отправлено: lastcross от Июня 28, 2017, 11:39:58 am
Не в проекте, а в рабочей папке. Там этих проектов сотни самых разных. И это не только исходники – там же и необходимые файлы для работы программ и сами исполняемые файлы. И я пока не планирую разделять исходники, исполняемый файл и данные для его работы – это мне неудобно.

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


Цитировать
Я тоже не про язык. Я про инкапсуляцию данных.
Именно разделение всех частей участвующих в построение проекта - и есть инкапсуляция (изменения в одном репозитории сокрыты от изменений в другом)

Цитировать
Кстати, интересно, как git справится со слиянием изменений при одновременной правке файла, например, типа doc. Думаю, что никак.
Он справляется - всегда можно принять правки свои или чужие. Мержить бинарные файлы, с автоматическим резолвом конфликтов - не стоит.
Вообще, для документации советую вам смотреть в сторону wiki-like сервисов.

Цитировать
Ну, я меня он ругается, что не может прочесть проект:
Пробуйте так

Цитировать
D:\GIT\1>git clone d:\GIT\Project\TestOrtohonalization

или так

Цитировать
D:\GIT\1>git clone d:\GIT\Project\TestOrtohonalization\.git

Если TestOrtohonalization - это папка под гитом


Название: Re: Система контроля версий Git
Отправлено: da-nie от Июня 28, 2017, 07:47:17 pm
Цитировать
Не совсем удачное решение. Я бы даже сказал - совсем неудачное!

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

Цитировать
Мержить бинарные файлы, с автоматическим резолвом конфликтов - не стоит.

Вот я про то, что doc близок по структуре к бинарнику. Тут просто изменение строки не отследить. Если только у git нет специального модуля для таких файлов.

Цитировать
Вообще, для документации советую вам смотреть в сторону wiki-like сервисов.

Спасибо за совет, но я её совместно почти не пишу. Так что... Пока не требуется. :)

Цитировать
Если TestOrtohonalization - это папка под гитом

Да, это папка с тестовым проектом в каталоге d:\GIT\Project. Но никак не клонирует. адо на семёрке попробовать - может, дело в той самой ошибке на XP.


Название: Re: Система контроля версий Git
Отправлено: lastcross от Июня 29, 2017, 01:34:35 pm
У каждого проекта своя специфика. И чтобы не запутаться, мне нужно рядом с проектом хранить всё то, что он использует. Это даже для отладки нужно. А вот пользователь получит обновление по сети с сервера, как только я решу, что проект работает верно и отправлю программу туда.

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


Цитировать
Вот я про то, что doc близок по структуре к бинарнику. Тут просто изменение строки не отследить. Если только у git нет специального модуля для таких файлов.
Изначально - дифф и мерж с резолыом у гита основывается на текстовых фалах. Хотите чтобы умел больше - да, ищите к нему отдельные модули.
Не пользовался, но говорят pandoc (http://blog.martinfenner.org/2014/08/25/using-microsoft-word-with-git/) что-то умеет

Цитировать
Спасибо за совет, но я её совместно почти не пишу. Так что... Пока не требуется. :)
Дело ваше, но совет был дан опять же не для "совместного" написания, а возможности хранения историй изменений и публикации (доступности для прочтения по ссылке)

Цитировать
Да, это папка с тестовым проектом в каталоге d:\GIT\Project. Но никак не клонирует. адо на семёрке попробовать - может, дело в той самой ошибке на XP.

Если в папке TestOrtohonalization есть папка .git - то указанные мной рекомендации по команде должны отрабатывать (уж не знаю как там на windowsXP =) ), по крайней мере у меня они работают


Название: Re: Система контроля версий Git
Отправлено: da-nie от Июня 29, 2017, 08:09:39 pm
Цитировать
Зачем Вам контроль версий? Ну право же - это инструмент (который требует другой подход к организации рабочего процесса), и Вам он вероятно понадобился.

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

Цитировать
Ваш текущий ответ звучит как - "я привык забивать гвозди, поэтому я забиваю и шурупы".

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

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

Нет никакого тестера. :) Ну не так у нас всё. Я ж сказал, у меня тут НИИ. Помилуйте, какой тестер! Руководство просит методику тестирования отдельным документом издавать! Это, я так понимаю, тест, который программа всегда пройдёт (кто ж туда запишет тест, который программа не пройдёт? Такой тест давно исправлен в программе. И я когда аттестовывался на инженера первой категории, они меня спрашивали, как мы тестируем ПО. Ну как? В составе комплекса испытываем и проверяем. Плохо, говорят. Ничего вы не понимаете в этом - должен быть документ, который "методика". Надо само по себе, говорят, тестировать. Лолшто? Без аппаратуры комплекса? :) И на полном серьёзе эти маразматики считали, что без документа "методики тестирования" наше ПО будет плохим. Им в этом видится проблема с ПО. Это ещё ничего, они меня на полном серьёзе спрашивали первые две цифры ГОСТ'а на ПО. ??? Откуда мне знать? Я его даже открывать не собираюсь - он мне сто лет не нужен. Да они и сами не знают, что там написано. Только эти первые две цифры и знают.). Пользователи у нас сугубо внутренние. Если что-то не пойдёт, они позвонят и позовут (и даже если всё пойдёт, тоже позовут - они часто не читают инструкции по использованию ПО и удивляются странным результатам испытаний приборов - а нефиг нажимать на блоке или в программе то, чего не надо и не нажимать то, что надо). Руководство (директор и прочие) у нас вообще не понимает, почему с уходом "погромиста" ПО получается не поддерживаемое и не сопровождаемое. Они вообще в ПО ничего не понимают, но свои цидульки на эту тему писать не стесняются. Сейчас вот какую-то хрень (ФИКС, вроде называется, но не уверен) желают к архиву прикрутить. Зачем она им... Что это вообще такое?
Но начальник отдела часто надоедает мне, как всё это исправить. Ага. Имея два-три человека, которые занимаются каждый своим проектом (и электроникой, и часто чертежами, и сдачей в архив, и программой, и отладкой, и тестированием, и написанием инструкций). :) Люблю юмор, но, почему-то, не таких юмористов. Но кое-что я бы внедрил. Например, систему контроля версий. Ну вот кажется мне, что она могла бы быть полезной. Ещё не знаю, как, но кажется. :)

Цитировать
Все кто это осознал - не могут представить как что-либо серьезное кодить/разрабатывать без этой возможности.

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

Я понимаю, что вас удивляет мой подход. :) Но вот была такая юмористическая статья когда-то (я выделил только некоторые абзацы):
Код:
...
Ученику выдается компьютер и некоторое количество программных средств, с
которыми ему в дальнейшем придется работать. Описаний к этим программам либо не
выдается совсем, либо выдается минимальный набор. Если происходит обучение
какому-либо языку программирования, в качестве руководства желательно
использовать литературу на языке, заведомо незнакомом обучающемуся, либо
произведения советских авторов.
Когда будет замечено, что ученик работает с программой (языком программирования)
довольно сносно, можно предложить ему для изучения исчерпывающие руководства.
Они будут прочитаны как захватывающий детектив. Затем, после небольшого периода
переваривания полученных знаний, программист готов к активной деятельности.
Специалист, прошедший обучение подобным образом, как правило, удивляет других
программистов приемами программирования. Не исключено, что вместо
шестнадцатиричной системы счисления он будет использовать десятичную (если ему
до прохождения курса никто не объяснял, что программировать нужно в
шестнадцатиричной системе). Программы, написанные таким специалистом, будут
совершенны в работе, но перед желающим их улучшить или изменить встанет
практически неразрешимая задача (за исключением случаев, когда с этой задачей
сталкивается такой же специалист), так как прочитать эти программы и понять их
суть крайне тяжело, например, нелегко обычному программисту прочитать программу
на Ассемблере, в которой все числа - десятичные.
...
все, что хакер делает, он не считает работой, и если фирма платит ему деньги,
то, вероятно, только для того, чтобы он иногда произносил фразу: "Я работаю на
фирме ...";
...
хакер не всегда знает язык программирования, с которым он в данный момент
работает;
хакер способен объяснять по телефону способ, которым можно найти ячейку памяти,
определяющую количество жизней в игре SABOTEUR, одновременно восстанавливая
содержимое диска с полностью испорченной директорией, используя DISC DOCTOR
фирмы Technology Research (программу, написанную либо пьяным, либо сумасшедшим);
...
как правило, критику хакер воспринимает без мордобития, всегда находит
оправдание, но указанную ошибку исправляет (если ее не исправил другой хакер);
хакер может страдать тяжелой формой мании величия, но всегда об этом
предупреждает;
мыслительный процесс идет у хакера подсознательно. Это иногда приводит к тому,
что ложась с женщиной в постель, хакер вскакивает, осознав, что в пятисотой
строке его программы стоит неправильное условие перехода на метку QWERTASDF
(такая метка также в порядке вещей, так как хакеру не хватает энергии не только
на написание комментариев, но и на придумывание удобочитаемых меток - гораздо
проще провести кулаком по клавиатуре).
...
Поскольку сейчас в советских магазинах нельзя купить не только пакет P-CAD для
IBM PC, но и колбасу, хакер часто начинает с того, что собственными силами
собирает компьютер. Естественно, что это игрушка для дома и семьи с
восьмиразрядным процессором и памятью в пределах 64К, но именно на таком
аппарате хакер начинает воистину вытворять чудеса. Описать ощущения, вызываемые
сообщением языка Си "Числа с плавающей запятой не поддерживаются" после 3-х
минутной подгрузки библиотеки stdio.h с магнитофона, невозможно, это надо
прочуствовать.
...
Хакер некоторое время ходит вокруг машины (радиус хождения может
составлять до нескольких тысяч километров), затем садится за клавиатуру и делает
за один вечер то, на что было выделено 15 дней. Не надо думать, что четырнадцать
дней, которые хакер потратил на хождение вокруг машины пропали даром: все это
время хакер подсознательно обдумывал поставленную задачу. Другое дело, была ли
необходимость в этих раздумьях.
Когда хакер заканчивает какую-либо работу, он твердо уверен: все, что он сделал
- хлам, однако вслух это мнение не высказывает, так как заказчик всегда остается
доволен. Хакер, конечно, расстроится, если случайно уничтожит шестимесячную
работу, но глубоко в душе он будет рад тому, что, расставшись с хламом, он
сможет решить задачу гораздо красивее.

 :D :D :D

Хоть Saboteur у меня и был (но он мне не был интересен - вечные жизни я ставил в других играх, например, в Dynamite Dan-2 или Dizzy-4), но TR-DOS'а не было - на моём ZX был только магнитофон. Что касается Hisoft C, то да, едва набрав #include <stdio.h> этот чудо компилятор сразу требовал загрузить эту библиотеку с ленты. :) Только у меня её не было в пакете. :) Сам компьютер, впрочем, был магазинным - на тот момент я не слишком понимал, как он работает. Ну и метки у меня изначально были аккуратные (комментарии тоже имелись). :) А в остальном почти биография. :) И десятичная система в ассемблере. :)

Цитировать
а возможности хранения историй изменений и публикации

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

Цитировать
Если в папке TestOrtohonalization есть папка .git - то указанные мной рекомендации по команде должны отрабатывать

Да. Есть. Но не работает. Надо на Windows 7 попробовать будет.


Название: Re: Система контроля версий Git
Отправлено: da-nie от Июля 04, 2017, 10:27:35 am
Под Windows 7 всё работает правильно. Клонирует без проблем. :)