Search
Write a publication
Pull to refresh

Comments 24

UFO landed and left these words here
Почта хороша когда разработка в ветке/проекте ведется небольшой командой. У меня вот например бывало по двести писем в день. Нет, я конечно их фильтрую в отдельный каталог, но сам факт постоянного оповещения о приходе писем…

Интересен момент, можно ли установить разные действия на разные ветки проекта, но при этом не выделять их как отдельный проект?
Если я правильно понял, то нельзя. Один проект — одна ссылка на ветку в репозитории — одно действие.
В таком случае, правильнее было бы обновлять рабочий каталог перед коммитом или смотреть логи — времени займет столько же сколько поиск нужной информации в почте, а достоверность информации в первоисточнике(svn) выше. Тут же всё просто, видишь иконка мигает — обновись.
SVN Monitor или его более свежая версия — Vercue (правда платное и дорогое). Все остальное при проверке — не так удобно.
Предпочитаю работать с svn децентрализованно — из консоли, в интеграции с системой(ToroiseSVN) и из IDE. CommitMonitor дает мне возможность видеть обновления независимо от источника. Vercue — решение в себе. Не вижу особого преимущества, которое стоило бы 40 или 100 евро. Конечно, в единой точке входа в svn свои плюсы, но и проблемы там другие, а не те которые описаны в статье.
Проблема, описанная в начале, о поиске 3х файлов из ста для комммита — решается changeset'ами в тортилке — если надо выделить измененные файлы в некий логический набор — это changeset. Быстро находится и легко выделяется.

Ваше решение проблемы поиска — поддержание актуальной копии чтобы не «прохлопать» сильное расхождение — оно успешно решается обоими утилитами, только коммит монитор — простенько и без опций, а SVNMonitor — более проработано — можно посмотреть изменения, автора, те же нотификации есть. Просто попробуйте настроить и поработать 3 дня — увидите преимущества. А не попробовав — конечно не видно. Я перепробовал много разных утилит для мониторинга после того как автор сделал дорогой Vercue и забросил svn monitor — удобней всего концепция именно как в svnmonitor\vercue — очень естественный и логичный набор действий.

И если вдруг решите все-таки попробовать — советую сразу брать старый svnmonitor т.к. он бесплатный, а если втянуться в фичи Vercue — тяжело слезать будет…
Ваша проблема решается гораздо проще: «Right click/TortoiseSVN/Settings/Dialogs 2/Reopen commit and branch/tag dialog after a commit failed» и будет Вам счастье: коммит диалог не закроется и отмеченные файлы останутся. Просто обновите воркинг копи из другого окна TortoiseSVN, и коммитьте опять.

Авотматические обновления рабочего каталога плохая практика из-за возможных конфликтов,
и — самое опасное — файл кот. редактируется в данный момент может быть изменен,
и последствия будут непредсказуемыми.
Спасибо. Это то, что нужно.
Тем не менее, программы-мониторы удобны в получении актуальной информации об изменениях. А автообновление легко отключить во время разработки. К тому же многие ветки не редактируются, а просто служат целью для мержа.
> Хорошо когда коммитить нужно всё, а если нужны лишь три файла из ста?
Руки бы отрывал.
Конечно это нежелательная практика, но такова реальность больших проектов.
Как раз на больших проектах последствия частичных коммитов тяжелее всего. Кто-то один при частичном коммите «ой забыл файлик добавить», а остальная команда потом полдня курит, потому что билд не собирается.
Такие последствия тяжелы на проекте любой величины.
На больших проектах вероятность появления всяких svn-артефактов увеличивается. Появляются кучи призрачных файлов и директорий, которые маячат из коммита в коммит. Их то и приходится игнорировать при коммите своих изменений.
svn:ignore придумали трусы.
а если файл-призрак — часть моих изменений?
Так. Он либо «призрак» и не нужен в репозитории, тогда при чем тут изменения. Либо он нужен в репозитории, является частью кода, и тогда давайте конкретнее на примерах.
Под «призраком» я понимаю файл, который постоянно маячит в коммитах. Среди них может быть и обычный файл проекта. Т.е. в файле изменений нет, а он всё-равно отображается как измененный. Вот такие артефакты порой появляются из-за ошибочных коммитов или проблем самого svn. С ростом проекта их число только увеличивается.
> Под «призраком» я понимаю файл, который постоянно маячит в коммитах. Среди них может быть и обычный файл проекта. Т.е. в файле изменений нет, а он всё-равно отображается как измененный.

Сколько лет работаю с svn/cvs/hg, никогда такого не видел.
Файл либо изменен локально, и тогда легко ловится по svn status, либо изменен другим пользователем и закоммитан — тогда он на сервере, и придет к вам в рабочую копию при svn update.
Может быть эта проблема связана с багами в svn-клиенте, который вы используете?
Удобная штука, поставил себе.
Позволяет вовремя апдейтиться, и держать «руку на пульсе» проекта, за который я несу ответственность.
PhpStorm оповещает об изменениях в репе, внизу в трее иконка загорается
Sign up to leave a comment.

Articles