>>Будут ли в истории файла B
Проделал небольшой эксперимент на 'hg init proba'.
Что сделал?
1) добавил 1.txt
2) Заем изменил его
3) далее переименовал 'hg rename 1.txt 2.txt'
4) закомитил переименование
5) изменил 2.txt.
6) Посмотрел history на файл.
итог: Историю вижу вплоть до коммитов по 1.txt
>>То есть, rename не умеет
Я правильно понял, что use-case такой: Вы переименовали файл с помощью функций вашего bash или другой плюшки операционной системы и хотите от среды контроля версий чтобы она догадалась что вон тот файл на самом деле не просто добавлен, а что он ничто иное как переименованная копия прежнего файла?
Сохраняется история! Это одно из требований при разработке Mercurial. К примеру в коммите писал одно «Added ReadPe class and module with the class», а вот в одном из информационном поле на файле помимо сообщения коммита в TortoiseHg показывается: «ReadPE/tools/readpe.py (was added)». Аналогичное поведение и для delete.
Есть команда 'hg rename'. Она выполнена в виде 'hg delete'/'hg add', но с пометкой че и откуда и куда. Точно такое же поведение и 'hg move'. Юниксоиды так вообще предпочитают 'hg mv', мне говорят «что это им роднее», возможно…
В том-то и дело, что самые умные мысли приходят не сразу! А хорошо если в начале процесса разработки, но как правило либо где-то посередине, либо из-за обнаруженного нюанса, нового требования или еще чего-нить иногда и структуру проекта нужно изменять. Программисты, вообще о науке разработки ПО, уже пробовали спроектировать на самом первом этапе, не осилили и пришли к тому что сейчас более менее вменяемо это работа по Agile-практикам или около-них
Согласен.
Добавлю еще несколько слов по поводу того что дал мне Mercurial и чего не может дать мне SVN используемый на работе.
Резюме нижесказанного: Mercurial поощряет экспериментирование без которого, нам разработчикам, иногда не возможно развиваться или решать задачи.
Иногда в нашем мозгу возникают идеи, которые похожи на бред, но тут же возникает другая мысль: «А вдруг? Почему нет?». Для того чтобы получить ответ на вопрос: «бред или нет?» мы должны хотя бы немножко, хотя бы чуть-чуть этот бред запилить. При повседневном использовании Меркуриала мы замечаем, что все вертится вокруг одной папки это '.hg'. После того как мы после 2 дней экспериментирования понимаем, что мы написали бред, то мы просто удаляем одну папку! Наши попытки «наговнокодить» никакого не задели, ни физически, ни морально(а ведь на это же мог кто-то поглядеть :)))
1)
Можете ли Вы пользуясь SVN также быстро получать ответы на свои вопросы и при этом ни кого не трогая без особой нужды?
2)
Если Ваш коллега сидит от Вас за 7-8 метров и ему лень вставать(как часто Вы слышали: «Путь, ну млин, айда позже?»). В меркуриал это одна команда «hg serve». Вы поднимаете у себя локально вэб-сервер и даете ссылку по аське, жаберу или идете лично и вбиваете ему в гугле-хроме(или еще где) и человеку уже не отвертеться «гора сама пришла»
3)
Насколько легко вы мержите ветки? И как часто их применяете? Не знаю, может у меня руки не из правильного места, но в SVN мержить ветки так и не научился. А в Mercurial это все как будто само за меня делается. Я к тому что сложности юзания веток не только у меня, но и у других, даже матерые девелоперы избегают этой процедуры. Это выливается, что команда комитит в HEAD даже не рабочий код, только лишь из соображений «А вдруг я завтра не смогу придти на работу?». Меркуриал же поощрает «одна задача одна ветка и одна всесильная под названием stable»
4)
Безболезненая смена ответственного за фичу.
В любой момент разработки продукта могут пилиться абсолютно разные фичи по которым люди также имеют абсолютно разный уровень знания. Как вывод по новой разрабатываемой фиче куда выгоднее иметь разработчика который больше всего подходит именно для этой фичи и назначить его мантейнером. В случае SVN репа «гвоздями прибита» к одному компу, в случае Mercurial можно в любой момент времени создать репу на компе конкретного разработчика. Если же он вдруг меняется, у других ребят кто пилит с ним эту фичу есть локальные копии со всем необходимым и если мантейнер заболел, забухал или еще что, на команде это не сказывается.
Более-того, если все пилится по схеме «одна фичи одна ветка», то мантейнером за stable назначается тестировщик, что куда выгоднее. Команда всегда знает что от туда можно взять стабильно работающий код, ибо за него несет ответственность тестировщик.
Заглянул в Ваш профиль, увидел ссылку, кликнул, понеслась… Вы умеете себя презентовать. Может напишите топик со своим мнением о том как надо себя презентовать современному разработчику?
ЗЫ: Может кто-то как и я лазит по чужим анкетам и смотрит в инфо хабраюзерах. Мне кажется этот чел должен поделиться знаниями. Или я не прав? )
>>значит комманду (и вас) он или устраивает
Ну не то чтобы устраивает… но Вы сами понимаете что не все так просто. Ведь переход на что-то новое это же не просто взял и насетапил ) Это еще и договориться о новых стандартных схемах использования. Более того всегда кто-то за, а кто-то против и этих «динозавров» надо «уговаривать» или учить навыкам работы. А иногда просто между версиями до след. релиза слишком мало времени. Вобщем переход с одного на другое занимает определенное человеко-время )
Мне кажется что создавая этот опрос Вы хотели знать ответ на вопрос «А сколько реально коммерческих продуктов создается тем или иным средством?». Только вот не учли, что программер может и дома программить зарабатывая себе на хлебушек. Более того несмотря на тот факт, что программер может добросовестно относиться к работе и делать достаточно много для компании где работает днем, ему тем не менее никто не мешает сделать куда больше коммитов в какой-нить open-source проект дома.
Схем взаимодействий между программерами очень и очень много и говорить «выбирай чтото одно», а потом на основании этой статистики по сделанным выборам что-то оценивать, на мой взгляд не очень корректно
Жалко нельзя две выбрать, к примеру на работе человек может юзать одно средство, а вот придя домой учавствуя в гитхаб или битбакет проектах совершенно другое. Да и не важно какое чаще юзаешь, главное ведь результат. Отметил SVN, ибо юзается у дяди дающего денюжку
Вы полагаетесь на Ваш реальный опыт исследования малвары или строите предположения?
«Делание скриншота» достаточно легко детектируется, а вот «сбивание» этого детекта достаточно дорогая операция! Именно по этой причине большинство тех, кто пишет подобные вещи стремятся избежать этой операции(делания скриншота). Ради интереса можете поспрашивать на некоторых сайтах, а их немало, что и сколько будет стоить.
Всегда мечтал чтобы виртуальные клавиатуры хотя бы порядок цифер делали рандомным, человеку хоть и будет неудобно, но он их сможет найти. Зато реализация троянов чуть-чуть усложняется и появляется больше признаков по которым их можно ловить
Вы забыли об виде энтузиазма, который возникает во время качания ребенка на руках и возникшей мысли «Да это же можно сделать так...», а за ней ворох других мыслей и хочется прям сию секунду побежать и понаписать коду, который решит половину задач из Нашего туду-листа. Но нельзя. Ребенок. Сейчас нужно качать. Качаем. Проходит полчаса. Заснули. Садимся за комп и видим от нашей идеи 1-2 полезные мысли, а остальные не работают из-за того что забыли тонкости языка, требований. В сухом остатке остаются эти самые 1-2 созревшие мысли, которые по-настоящему решают Нашу задачу.
Ничуть не теряют, но уже не бегут сломя голову на любую вновь появившуюся технологию. Становятся более честными к самим себе и людям, и реальней относятся к своим возможностям. Появляется реальное ощущение что вон-ту фигню запилю за такое-то время, а не как это было в 20 лет «Да я че не пацан чтоли? Да за два часа!!! Легко!».
Я бы сказал 30 — 40 летние должны по-любому быть в любой компании в таком же количестве, что и 20-летние. Они более степенней, а рынку нужны не только свежие и модные фичи, но также и стабильные!
Никто не убеждает. Вас просят перечислить список недостатков которые вы заметили в Gyp в результате которых вы приняли решение что не нравится? Это только из-за синтаксиса Gyp, правильно понял?
Проделал небольшой эксперимент на 'hg init proba'.
Что сделал?
1) добавил 1.txt
2) Заем изменил его
3) далее переименовал 'hg rename 1.txt 2.txt'
4) закомитил переименование
5) изменил 2.txt.
6) Посмотрел history на файл.
итог: Историю вижу вплоть до коммитов по 1.txt
>>То есть, rename не умеет
Я правильно понял, что use-case такой: Вы переименовали файл с помощью функций вашего bash или другой плюшки операционной системы и хотите от среды контроля версий чтобы она догадалась что вон тот файл на самом деле не просто добавлен, а что он ничто иное как переименованная копия прежнего файла?
ЗЫ:
Я не гуру, но пока сюрпризов не видел )
В меркуриал это:
$(ProjectRoot)>\ hg ci -A -m «Project file structure changed»
где:
-A --addremove mark new/missing files as added/removed before committingДобавлю еще несколько слов по поводу того что дал мне Mercurial и чего не может дать мне SVN используемый на работе.
Резюме нижесказанного: Mercurial поощряет экспериментирование без которого, нам разработчикам, иногда не возможно развиваться или решать задачи.
Иногда в нашем мозгу возникают идеи, которые похожи на бред, но тут же возникает другая мысль: «А вдруг? Почему нет?». Для того чтобы получить ответ на вопрос: «бред или нет?» мы должны хотя бы немножко, хотя бы чуть-чуть этот бред запилить. При повседневном использовании Меркуриала мы замечаем, что все вертится вокруг одной папки это '.hg'. После того как мы после 2 дней экспериментирования понимаем, что мы написали бред, то мы просто удаляем одну папку! Наши попытки «наговнокодить» никакого не задели, ни физически, ни морально(а ведь на это же мог кто-то поглядеть :)))
1)
Можете ли Вы пользуясь SVN также быстро получать ответы на свои вопросы и при этом ни кого не трогая без особой нужды?
2)
Если Ваш коллега сидит от Вас за 7-8 метров и ему лень вставать(как часто Вы слышали: «Путь, ну млин, айда позже?»). В меркуриал это одна команда «hg serve». Вы поднимаете у себя локально вэб-сервер и даете ссылку по аське, жаберу или идете лично и вбиваете ему в гугле-хроме(или еще где) и человеку уже не отвертеться «гора сама пришла»
3)
Насколько легко вы мержите ветки? И как часто их применяете? Не знаю, может у меня руки не из правильного места, но в SVN мержить ветки так и не научился. А в Mercurial это все как будто само за меня делается. Я к тому что сложности юзания веток не только у меня, но и у других, даже матерые девелоперы избегают этой процедуры. Это выливается, что команда комитит в HEAD даже не рабочий код, только лишь из соображений «А вдруг я завтра не смогу придти на работу?». Меркуриал же поощрает «одна задача одна ветка и одна всесильная под названием stable»
4)
Безболезненая смена ответственного за фичу.
В любой момент разработки продукта могут пилиться абсолютно разные фичи по которым люди также имеют абсолютно разный уровень знания. Как вывод по новой разрабатываемой фиче куда выгоднее иметь разработчика который больше всего подходит именно для этой фичи и назначить его мантейнером. В случае SVN репа «гвоздями прибита» к одному компу, в случае Mercurial можно в любой момент времени создать репу на компе конкретного разработчика. Если же он вдруг меняется, у других ребят кто пилит с ним эту фичу есть локальные копии со всем необходимым и если мантейнер заболел, забухал или еще что, на команде это не сказывается.
Более-того, если все пилится по схеме «одна фичи одна ветка», то мантейнером за stable назначается тестировщик, что куда выгоднее. Команда всегда знает что от туда можно взять стабильно работающий код, ибо за него несет ответственность тестировщик.
1) Сайт: neithere.net
2) neithere.net/dev/ и т.д. и т.п.
ЗЫ: Может кто-то как и я лазит по чужим анкетам и смотрит в инфо хабраюзерах. Мне кажется этот чел должен поделиться знаниями. Или я не прав? )
Ну не то чтобы устраивает… но Вы сами понимаете что не все так просто. Ведь переход на что-то новое это же не просто взял и насетапил ) Это еще и договориться о новых стандартных схемах использования. Более того всегда кто-то за, а кто-то против и этих «динозавров» надо «уговаривать» или учить навыкам работы. А иногда просто между версиями до след. релиза слишком мало времени. Вобщем переход с одного на другое занимает определенное человеко-время )
Мне кажется что создавая этот опрос Вы хотели знать ответ на вопрос «А сколько реально коммерческих продуктов создается тем или иным средством?». Только вот не учли, что программер может и дома программить зарабатывая себе на хлебушек. Более того несмотря на тот факт, что программер может добросовестно относиться к работе и делать достаточно много для компании где работает днем, ему тем не менее никто не мешает сделать куда больше коммитов в какой-нить open-source проект дома.
Схем взаимодействий между программерами очень и очень много и говорить «выбирай чтото одно», а потом на основании этой статистики по сделанным выборам что-то оценивать, на мой взгляд не очень корректно
«Делание скриншота» достаточно легко детектируется, а вот «сбивание» этого детекта достаточно дорогая операция! Именно по этой причине большинство тех, кто пишет подобные вещи стремятся избежать этой операции(делания скриншота). Ради интереса можете поспрашивать на некоторых сайтах, а их немало, что и сколько будет стоить.
Я бы сказал 30 — 40 летние должны по-любому быть в любой компании в таком же количестве, что и 20-летние. Они более степенней, а рынку нужны не только свежие и модные фичи, но также и стабильные!