[AlexandrY 3]

между тем это ни то, ни другое.

 

И между чем же ?

Похоже вы как собака, все понимаете, но сказать не можете.

 

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

 

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

Ни о каких коммитах после каждого изменения уже речи не идет.

 

А что за приятные расширения?

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

[dxp 51]

Похоже вы как собака, все понимаете, но сказать не можете.

Могу много чего сказать на тему, но только человеку, который хочет в этом разобраться, а не троллить как вы. Оставайтесь при своём.

 

 

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

Вот именно.

[Grizzly 0]

И между чем же ?

Похоже вы как собака, все понимаете, но сказать не можете.

 

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

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

Изменено 3 февраля, 2016 пользователем Grizzzly

[AlexandrY 3]

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

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

 

Тогда видимо надо уточнить что вы собственно программируете.

Что такое "задача" в вашей технологии? Почему им нужны ветки?

Вам мало дерева проекта в собственной IDE?

 

Проверьте размер ваших служебных файлов системы контрооя версий. Они действительно меньше гигабайта?

Какой размер проекта тогда у вас и насколько длинная его история?

 

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

[ashr 0]

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

Мне это высказывание напоминает вот такую позицию некоторых людей:

"Я не нашел никакого способа или технологии, которые позволили бы с помощью RTOS экономить ресурсы процессора, они всегда осью только отнимаются."

 

Прям один в один аналогия :)

[Grizzly 0]

Тогда видимо надо уточнить что вы собственно программируете.

Что такое "задача" в вашей технологии? Почему им нужны ветки?

Вам мало дерева проекта в собственной IDE?

 

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

 

Идеология Git такова, что любое исправление или добавление пусть самой маленькой функции в несколько строк вполне считается задачей. Для нее делается ветка, в которой отлаживается все. Параллельно приходит задание починить что-то другое, срочно. Для чего из master создается ветка, в которой происходит исправление бага. Затем после отладки сливается на сервер ответственным за данный репозиторий. Таким образом, master всегда в том состоянии, что из нее можно генерировать прошивку. Там нет чего-то такого, что положит проект на некоторое время. Менее квалифицированные сотрудниики не внесут катастрофических изменений.

Например, на Хабре описан стиль такой работы: https://habrahabr.ru/post/75990/

 

IDE здесь ни при чем.

 

Проверьте размер ваших служебных файлов системы контрооя версий. Они действительно меньше гигабайта?

Какой размер проекта тогда у вас и насколько длинная его история?

Нет, больше. Проекту несколько лет. Только Git используется именно как инструмент, позволяющий эффективно вести работу.

 

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

 

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

 

P.S. Я не настаиваю использовать системы управления версиями именно таким образом. У каждого могут быть свои представления. Попытался объяснить преимущества именно такого подхода, под который создавалась сама система.

Изменено 3 февраля, 2016 пользователем Grizzzly

[AlexandrY 3]

Затем после отладки сливается на сервер ответственным за данный репозиторий.

 

Я уже долблю несколько постов подряд. Меня не интересует командная работа!

 

Я изучаю вопрос что дает контроль версий индивидуальному разработчику или разработчику слабо связанному с командой.

Или что он дает разработчику вне рамок взаимодействия с командой.

Что контроль версий может предложить для повышения личной производительности. За команду пускай думает начальство.

 

Ветки для пары изменений пока выглядят в личном плане как критическое излишество.

 

И что такое "бэкпортирование"?

Как контроль версий помогает портированию?

 

"Я не нашел никакого способа или технологии, которые позволили бы с помощью RTOS экономить ресурсы процессора, они всегда осью только отнимаются."

 

Это абсолютная правда. RTOS экономит ресурсы разработчика, а не процессора.

[Grizzly 0]

Я уже долблю несколько постов подряд. Меня не интересует командная работа!

 

Я изучаю вопрос что дает контроль версий индивидуальному разработчику или разработчику слабо связанному с командой.

Или что он дает разработчику вне рамок взаимодействия с командой.

Что контроль версий может предложить для повышения личной производительности. За команду пускай думает начальство.

 

Ветки для пары изменений пока выглядят в личном плане как критическое излишество.

 

Наверное, в этом случае выгод будет меньше. Навскидку приходит только такая ситуация: допустим, вы захотели что-то изменить в проекте, работаете над этим изменением, в это время заказчик сообщает об ошибке. У вас сейчас в основной ветке не совсем рабочая версия, поскольку что-то допиливате. А вдруг обнаружится 2-3 ошибки. Тогда лучше master не трогать, для каждой проблемы создать ветку, а потом уже слить воедино. Не стоит бояться такого числа веток. Их может быть параллельно десяток. После того, как вы отработали и слили ее, она запросто удалается.

 

И что такое "бэкпортирование"?

Откат к более страым версиям проекта: https://ru.wikipedia.org/wiki/Бэкпорт. За время работы многое в текущих проектах ушло вперед, но есть некоторые места, которые лучше были сделаны в самом начале, со временем вынужденно проводились в них изменения. Все работает, но хотелось бы именно начальный вариант получить. Теперь для других проектов хочется получить то состояние и развивать проект дальше.

[Corvus 1]

Я уже долблю несколько постов подряд. Меня не интересует командная работа!

 

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

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

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

[111 0]

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

"Контроль версий" следовало бы переименовать в "контроль программиста".

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

 

Я же поюсав VCS пару лет пришел к выводу, что мне проще просто сохранить исходник под именем? в котором в конце я добавлю [2], [3] и т.д. для обозначения, чем использовать этого монстра, НАПРАСНО жрущего мое время (которое как известно деньги) и ресурсы компа

 

И если мне нужно будет выяснить/вспомнить "что же я поменял" я запущу Araxis и сравню исходники с разными цифрами в []

 

P.S. Я не настаиваю использовать системы управления версиями именно таким образом. У каждого могут быть свои представления. Попытался объяснить преимущества именно такого подхода, под который создавалась сама система.

Вы так и не объяснили в чем же ГЛАВНОЕ назначение VCS.

Хотя постоянно намекаете, что знаете это.

Просвятите же нас.

 

Не стоит бояться такого числа веток. Их может быть параллельно десяток.

И это называется "инструмент УПРОЩЕНИЯ работы программиста"

 

 

Откат к более страым версиям проекта: https://ru.wikipedia.org/wiki/Бэкпорт. За время работы многое в текущих проектах ушло вперед, но есть некоторые места, которые лучше были сделаны в самом начале, со временем вынужденно проводились в них изменения. Все работает, но хотелось бы именно начальный вариант получить. Теперь для других проектов хочется получить то состояние и развивать проект дальше.

Короче получается КАША из кучи старых и новых версий программы.

У меня язык не поворачивается назвать это "упрощением работы программиста"

[AlexRayne 7]

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

Ни о каких коммитах после каждого изменения уже речи не идет.

 

А что за приятные расширения?

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

 

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

 

расширения меркуриала без которых работа становится черной - mq, shelve, record, rebase, transplant. - они удачно представлены в УИ тортилы и смотрятся как родные.

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

Изменено 4 февраля, 2016 пользователем AlexRayne

[AlexandrY 3]

расширения меркуриала без которых работа становится черной - mq, shelve, record, rebase, transplant. - они удачно представлены в УИ тортилы и смотрятся как родные.

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

 

 

Почитал я про эти расширения. Они относятся все к той же истории с патчами и кучей веток.

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

 

Я так понимаю использование mq, shelve, record, rebase, transplant это такой корпоративный стандарт взаимодействия чтобы не дай бог не напороться на конфликт с коллегами.

Другого целевого конечного назначения у этих утилит не просматривается.

А жертвуется ради этого временем.

[Slash 0]

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

 

Это вы имеете ввиду папку .git в директории проекта, она занимает гиг?

[AlexRayne 7]

Почитал я про эти расширения. Они относятся все к той же истории с патчами и кучей веток.

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

 

Я так понимаю использование mq, shelve, record, rebase, transplant это такой корпоративный стандарт взаимодействия чтобы не дай бог не напороться на конфликт с коллегами.

Другого целевого конечного назначения у этих утилит не просматривается.

А жертвуется ради этого временем.

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

2) инструменты shelve, record - позволяют делать красивые комиты очищеные от мусора, и совсем необязательно в патчи. а rebase - как раз врезать отдельную ветку в линейную историю - тоесть устранять ветвистость.

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

 

[AlexandrY 3]

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

 

Ну опять. Это же все не для себя. А для "кого-то еще".

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

Ибо тогда никто ничего не сольет. Все должны работать и сливать только короткие и свежие участки кода.