Здравствуйте, catbert, Вы писали:

C>А как же Золотая Середина Синклера, что табы набиваем в соответствии с логическими отступами, а пробелы — чтобы красиво было?

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

Здравствуйте, WolfHound, Вы писали:

WH>+1
WH>Но нужно сделать выбор.
WH>Предлагаю два пробела.

Как я уже сказал — мне по фигу. Если большинство за пробелы, то я к нему присоединюсь.

Здравствуйте, Ziaw, Вы писали:

Z>Вообще в опенсорс проектах обычно выделяются несколько самых простых правил для стиля и описываются в небольшом документе для всех (это выравнивание, именование, основные правила обрамляющих {}), это можно положить в Docs. Этого обычно достаточно, чтобы пофиксить баг и не превратить код в кашу.

Z>Все остальное для внутреннего пользования командой разработки и достаточно ветки на этом форуме.

Я не очень понял смысл этого замечания. Зачем нам делать что-то тяп-ляп когда у нас есть полноценное описание?

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

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, catbert, Вы писали:

C>>А как же Золотая Середина Синклера, что табы набиваем в соответствии с логическими отступами, а пробелы — чтобы красиво было?

VD>У всех золотых середин есть одна проблема. Их тяжело определять на практике.

Да ладно, что там тяжелого, внутри каждого многострочного {} таб, а все остальное пробелами забивается...

Но мне как-то тоже все равно, так что куда большинство туда и я

Здравствуйте, Ziaw, Вы писали:

Z>Здравствуйте, VladD2, Вы писали:

Z>>>Сделал клон в котором закомитил свой обычный .hgignore (исключает из комита ненужные в репозитарии файлы) и файл со структурой каталогов.
Z>>>Посмотри, если все нормально — залью в центральный.

VD>>Вроде все ОК. А что нужно сделать мне, чтобы слить эту версию с основной?

Z>Да ничего, я сам залью. Но в принципе можешь и ты, требуются примерно такие действия:
...

Что-то многовато. А с помощью TortoiseHg это нельзя как-то упростить? Ведь это всего лишь слитие двух версий. В SVN как-то все было куда проще.

Здравствуйте, Ziaw, Вы писали:


Z>Сделал клон в котором закомитил свой обычный .hgignore (исключает из комита ненужные в репозитарии файлы) и файл со структурой каталогов.
Z>Посмотри, если все нормально — залью в центральный.

Файл dirhier.txt переименуй в dir-structure.txt или dir-hierarchy.txt, а то две минуты втыкаешь что это за базворд.

И наверно Libraries нужно сократить до Libs. Сокращение вполне стандартное. А смотреть на трехкилометровые пути в логах компиляции лично мне не очень хочется.

Здравствуйте, catbert, Вы писали:

C>Да ладно, что там тяжелого, внутри каждого многострочного {} таб, а все остальное пробелами забивается...

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

C>Но мне как-то тоже все равно, так что куда большинство туда и я

Ну, и мне тоже.

Здравствуйте, VladD2, Вы писали:

• перед началом работы, впишите в настройки репозитария или глобальные себя как автора в виде Alex Zimin <ziminav@gmail.com> иначе ваши комиты пойдут под именем пользователя в OS.
  
• если у вас стоит tortoisesvn — используйте его tortoisemerge и tortoisediff,
  
• чтобы не делать лишних мерджей, включите расширение mq. Теперь можно указывать в комбобоксах After pull значение Rebase, тогда ваши правки автоматом разместятся поверх вытянутых чужих. Merge не понадобится если не были задеты одни и те же строки.
  Эти три пункта делаются проще всего правкой конфига tortoisehg -> Global Settings -> Edit file
  

  [ui]
  username = Alex Zimin <ziminav@gmail.com>
  merge = tortoisemerge
  
  [extensions]
  mq=
  rebase=
  
  [tortoisehg]
  vdiff = tortoisemerge

  
  
  
• перед пулом, убедитесь, что все ваши правки закомичены, тогда они точно никуда не пропадут при неожиданном merge, вообще merge лучше делать тогда когда вы хотите, а не когда идет pull.
  
• вообще комиттесь чаще, это очень быстро, гарантирует безопасность правок и облегчает последующий merge конфликтов если они случились. Интересный факт, в rubymine, лучшем IDE для ruby отсутствует save, все правки сразу пишутся на диск. Никаких проблем это не вызывает, ибо большинство рубистов сидит на git, и функцию сохранить заменили себе комитом. Как только все работает, сделайте комит, потом будет легче понять, что же все таки сломалось.
  
• для быстрого комита сделайте кнопки на тулбаре студии, для этого добавьте в external tools две команды:
  
  

  Title: Show repository
  Command: %PROGRAMFILES%\TortoiseHg\hgtk.exe 
  Arguments: log
  Initial directory: $(SolutionDir) 
  
  Title: Commit
  Command: %PROGRAMFILES%\TortoiseHg\hgtk.exe 
  Arguments: commit
  Initial directory: $(SolutionDir)

  
  
  У студии есть один неприятный момент, изменения в csproj она хранит в памяти до одного ей известного момента, поэтому желательно проверять, ушел ли этот csproj в комит. Не знаю как с этим дела у немерловой интеграции. В принципе дома я использую VisualHg, работает стабильно, но кнопки на тулбаре все равно остались, к ним привык.
  
  
• Окно repository explorer (hgtk log) универсальное, все нужные операции делаются в нем, надобность в отдельных окнах incoming, outgoing, synchronize, changelog отсутствует начисто. Изучите его и диалог комита, больше для работы ничего не понадобится.
  
• Для экспериметального бранча проще всего сделать еще один клон репозитария. Склонировать локально репозитарий можно очень быстро.

Здравствуйте, VladD2, Вы писали:

Z>>>>Сделал клон в котором закомитил свой обычный .hgignore (исключает из комита ненужные в репозитарии файлы) и файл со структурой каталогов.
Z>>>>Посмотри, если все нормально — залью в центральный.

VD>>>Вроде все ОК. А что нужно сделать мне, чтобы слить эту версию с основной?

Z>>Да ничего, я сам залью. Но в принципе можешь и ты, требуются примерно такие действия:
VD>...

VD>Что-то многовато. А с помощью TortoiseHg это нельзя как-то упростить? Ведь это всего лишь слитие двух версий. В SVN как-то все было куда проще.

Многовато три команды? Ты вывод со вводом не перепутал? Первый сценарий вообще для того, у кого локального репозитария нет.

Обычно это две три команды Залить к себе правки, сделать мердж и отправить в центральный сервер.

С помощью TortoiseHg — hgtk log, вставляем урл клона в строку адреса вверху, жмем pull, смотрим что залилось, нужен ли мердж, меняем в адресе репо на default, жмем пуш. Кликов 10 без конфликтов наверное, это много?
SVN такая легкость не снилась даже.

Клоны с которыми ты работаешь запоминаются в настройках репозитария и обмен с ними происходит так же легко как и с центральным репо.

Здравствуйте, VladD2, Вы писали:

VD>Файл dirhier.txt переименуй в dir-structure.txt или dir-hierarchy.txt, а то две минуты втыкаешь что это за базворд.

Переименовал в DirHierarchy.txt, по аналогии с ExternalDependencies

Здравствуйте, VladD2, Вы писали:

Z>>Вообще в опенсорс проектах обычно выделяются несколько самых простых правил для стиля и описываются в небольшом документе для всех (это выравнивание, именование, основные правила обрамляющих {}), это можно положить в Docs. Этого обычно достаточно, чтобы пофиксить баг и не превратить код в кашу.

Z>>Все остальное для внутреннего пользования командой разработки и достаточно ветки на этом форуме.

VD>Я не очень понял смысл этого замечания. Зачем нам делать что-то тяп-ляп когда у нас есть полноценное описание?

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

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

Да я не против. Просто должен быть и краткий вариант в HowToContribute.txt, в котором можно сделать ссылку на полный. Когда таковая появится.

Здравствуйте, Ziaw, Вы писали:

Z>Многовато три команды? Ты вывод со вводом не перепутал? Первый сценарий вообще для того, у кого локального репозитария нет.

Ага, многовато. Пол экрана кода. В СВН чтобы мэнджуть брэнч нужно всего одну команду выполнить в тортиле.

Z>Обычно это две три команды Залить к себе правки, сделать мердж и отправить в центральный сервер.

Странно, что они не сделали отдельную команду прямо на гуглькоде.

Z>Клоны с которыми ты работаешь запоминаются в настройках репозитария и обмен с ними происходит так же легко как и с центральным репо.

Попробовал... вроде даже получилось что-то. Но как-то СВН сильно привычнее (от чего сильно проще).

Что ты имешь в виду под окном "log"? я такого не нашел.

В ТорлилаСВН есть очень удобное окно комита. В нем выводится список изменных и новых файлов и предоставляется возможность посмотреть див в человеческом виде. Как это же сделать в ТорлилаХг?

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Ziaw, Вы писали:

Z>>Многовато три команды? Ты вывод со вводом не перепутал? Первый сценарий вообще для того, у кого локального репозитария нет.

VD>Ага, многовато. Пол экрана кода. В СВН чтобы мэнджуть брэнч нужно всего одну команду выполнить в тортиле.

Ну, это ж консольный вариант... в TortoiseHG тоже просто.

VD>Попробовал... вроде даже получилось что-то. Но как-то СВН сильно привычнее (от чего сильно проще).

Это да...

VD>Что ты имешь в виду под окном "log"? я такого не нашел.

Repository Explorer в контекстном меню.. вызывается консольной командой hgtk log (кому как удобней).

VD>В ТорлилаСВН есть очень удобное окно комита. В нем выводится список изменных и новых файлов и предоставляется возможность посмотреть див в человеческом виде. Как это же сделать в ТорлилаХг?

Да так же, при комите. Только в Hg комиты локальные, поэтому для публикации изменений нужен еще один шаг — пуш на гугловый репозиторий.

Здравствуйте, Ziaw, Вы писали:

Z>Это не тяп-ляп. Это банальная вежливость и практичность, никто не будет пристально изучать стандарты кодирования в таком объеме чтобы просто поправить баг. Взгляни на другие проекты.

Стандарты нужны чтобы в них тыкать носом. А так конечно обычно люди просто смотрят на то, как пишут другие и делают так же. Но вот когда возникает необходимость попрвить человека, то проще сказать — смотри пункт x.y.

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

Z>Да я не против. Просто должен быть и краткий вариант в HowToContribute.txt, в котором можно сделать ссылку на полный. Когда таковая появится.

Краткий — это бесполезно. По нему все будут лепить что хотят. Нюансов очень много.

Здравствуйте, Ziaw, Вы писали:

Z>Переименовал в DirHierarchy.txt, по аналогии с ExternalDependencies

Вижу. А вот в проекты ты зря ExternalDependencies вставил. Все зависимости должны лежать в одном месте. Иначе потом задница будет. Потому в корне каталог и сделан. Я убрал это дело и сделал комит в основную копию.

ЗЫ

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

Здравствуйте, VladD2, Вы писали:

Z>>Многовато три команды? Ты вывод со вводом не перепутал? Первый сценарий вообще для того, у кого локального репозитария нет.

VD>Ага, многовато. Пол экрана кода.

Код это вывод hg, сами команды там предельно простые, это то, что находится между $ и //. Я просто все сделал у себя так, как будто у меня нет никакого репо и скопировал содержимое консоли.

VD>В СВН чтобы мэнджуть брэнч нужно всего одну команду выполнить в тортиле.

В hgtk тоже одна визуальная команда, удобнее svn тем, что в ней ты визуально видишь ветки которые конкретно мерджишь.
Еще две команды нужны чтобы взять бранч из клона и отправить полученные изменения в центр.

VD>Странно, что они не сделали отдельную команду прямо на гуглькоде.

Не стали заморачиваться, в общем случае там вероятен merge да еще и с конфликтами, веб интрефейс для всего этого дело муторное.

VD>Попробовал... вроде даже получилось что-то. Но как-то СВН сильно привычнее (от чего сильно проще).

Обычное дело для большинства переходящих, привыкнешь. Есть конечно на первый взгляд лишние движения (push & pull) но потом понимаешь, что без них еще хуже.

VD>Что ты имешь в виду под окном "log"? я такого не нашел.

hgtk log или Repositary explorer, я обычно даже в комит через него хожу, ибо иногда комичу несколько изменений несколькими комитами.

VD>В ТорлилаСВН есть очень удобное окно комита. В нем выводится список изменных и новых файлов и предоставляется возможность посмотреть див в человеческом виде. Как это же сделать в ТорлилаХг?

hgtk commit или комит в контекстном меню.

Здравствуйте, VladD2, Вы писали:

VD>6.2. Если вы инициализируете mutable начальное значение которой совпадает со значением для ее типа принятым по умолчанию, не указывайте начальное значение.
VD>

VD>// Используйте:
VD>mutable isOpen;
VD>// вместо:
VD>mutable isOpen = false;
VD>

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

Хорошо бы всегда иметь перед глазами конечное состояние проекта т.е. список фундаментальных и не очень фич.
которые, кстати наверное надо обсудить и отразить хотя бы в issues(, а может ещё как-то получше?)

Здравствуйте, para, Вы писали:

из мелочей: иметь возможность проходить отладчиком по коду макросов.

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

Здравствуйте, para, Вы писали:

P>запускать всю студию под отладкой как-то не айс, а просмотр значений переменных с помощью Message.Hint напоминает эру динозавров, когда писал распределённые вычисления на С .

assert2(false) и ходи по макрам на здоровье. Я как правило в этом случае запускаю не студию, а CLR Debugger.