Здравствуйте, lxAlexis, Вы писали:
A>Мне не только для инкремента версий надо. Необходимо там задавать какую-нибудь переменную в определённое значение и чтобы в зависимости от этого значения процесс компиляции шёл по разному (определённые файлы включались/не включались в jar, main-class менялся бы). Это можно сделать через .properties?
Не рекомендую вам смешивать автогенерируеме свойства и ручные. Особенно под Version Control. Выполнением target можно управлять с помощью аттрибутов if и unless. Соответственно, target выполнится если проперьть установлена или неустановлена соответственно.
Проперть установить в зависимости от содержимого проперти из файла можно с помощью таски condition и вложенным в него istrue.
<property name="my.property" value="true">
<condition property="my.Target.enabled">
<istrue value="${my.property}" />
</condition>
<target name="my.Target" if="my.Target.enabled">
</target>
Здравствуйте, aefimov, Вы писали:
A>Здравствуйте, denis_krg, Вы писали:
_>>1. Problems показывает состояние сразу всего проекта. Причем тут не ошибки важны, а warning'и. В ИДЕЕ вообще ничего на эту тему нет.
A>И очень хорошо, что в ИДЕИ нет этой дурацкой инкрементальной автокомпиляции. Знаем, что это очень круто. Знаем, знаем.
Представь себе ситуацию, что у тебя 5 разработчиков. Из них 3 не шибко квалифицированные. Надо оценить — что за фигню они там написали, но быстро, а не роясь в каждом классе. Вот тут то Problems и помогает.
И вообще, лучше, когда можно и так и этак.
_>>2. Работа с CVS в чем-то гораздо хуже (при редактировании), но при синхронизации зато можно увидеть — что же там народ наменял и решить — брать или не брать.
A>Все навески над стандартными функциями Version Control — это зло, приводящее к проблемам в репозитории. И в голове. У разработчика должен быть последний репозиторий. Он должен знать о проблемах. Он должен орать, что все сломалось. А когда каждый сидит и берет себе только те изменения какие ему нужны, в результате получается такая каша, что собрать ее вообще не возможно. Хотя, да — круто. Это мы тоже знаем.
Опять же, а что означает "стандартные функции VC"? Это на твой взгляд зло. А на мой — еще одна фича, благодаря которой я решаю некоторые свои проблемы. Ну к примеру. Если я много наменял (ну требует этого задача), а тут народ комититься, и это идет вразрез с моими изменениями? Что проще? Я могу посмотреть что они там наделали, взять и смержить, могу отложить, много чего могу.
Всем это может быть и не надо. Но опять же, мне лично это уже помогало.
А то, что ты говоришь насчет "каши" в голове у абстрактного разработчика, ну так и каша тогда тоже абстрактная.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Здравствуйте, denis_krg, Вы писали:
_>Представь себе ситуацию, что у тебя 5 разработчиков. Из них 3 не шибко квалифицированные. Надо оценить — что за фигню они там написали, но быстро, а не роясь в каждом классе. Вот тут то Problems и помогает.
Докаркались
http://www.intellij.net/forums/thread.jspa?threadID=221600&tstart=0
Demetra, build 5261 is available at http://www.intellij.net/eap
Changes in build 5261 from build 5245:
* Code coverage. Global report.
* Highlighting of files containing errors in project view and editor
tab titles.
* Scope "Problems" to display files containing errors.
Complete list of changes: http://jetbrains.net/jira/secure/ReleaseNote.jspa?projectId=10132&styleName=Html&version=10593
_>Опять же, а что означает "стандартные функции VC"? Это на твой взгляд зло. А на мой — еще одна фича, благодаря которой я решаю некоторые свои проблемы. Ну к примеру. Если я много наменял (ну требует этого задача), а тут народ комититься, и это идет вразрез с моими изменениями? Что проще? Я могу посмотреть что они там наделали, взять и смержить, могу отложить, много чего могу.
_>Всем это может быть и не надо. Но опять же, мне лично это уже помогало.
Вообще, когда народ комитится он берет и коммитится. И у него если закомитилось, то дальше это твое дело, коммитится или нет. Ибо мержится всеравно предется. Вот только размах этого мёржа в случае с IDEA будет меньшим.
