Спасибо, но у меня есть на что потратить свободное время, которого итак внатяг. Хороший аргумент на претензии к продукту с открытым исходным кодом — «Не нравится, пофиксь». Гугл, деньги вообще-то на нем зарабатывает, могли бы и сами подсуетиться.
Попробуйте посерфить, например, по испанскому магазину. Когда для определенных страниц перевод однозначно не нужен(по товару видно что страницу можно закрыть), а некоторые все таки хочется перевести.
Я люблю хром, но меня дико бесят его хинты типа «Перевести страницу?», из-за которых вся страница после открытия резко съезжает на пару десятков пикселов вниз.
— нет возможности удобно закоммитить часть изменений в файле
— неудобно делать pull с rebase
— неудобная навигация по репозиториям
— нет возможности сделать interactive rebase
В последней версии tortoiseHg все эти недостатки исправно отсутствуют и фичи прекрасно работают.
Мне эти устройства напоминают старые добрые мультимедийные клавиатуры, с десятком-другим мега нужных кнопочек, которыми поклацаешь первые пару дней, а потом забываешь про их существование. Надеюсь что я не прав.
Захочу — сделаю коммиты в главное хранилище, не захочу — не сделаю.
Скажите это тысячам девелоперов которые хостятся на gihub. Конечно, я не буду коммитить в опенсурс проект свои локальные доработки, если они никому не нужны, кроме меня. А если все ок, то без проблем сделаю Pull request.
При разработке коммерческого проекта такое исключено, иначе уволят вмиг.
Такие проблемы придется решать административным путем и в результате может получится та же централизованная система, но только реализованная на DCVS. А стоит ли?
Разве это проблема, поднять сервер hg и сказать чтоб все туда пушились по завершению работы? У нас именно так и произошло, 4 года — полет отличный.
2) проблемы со сквозной нумерацией. В SVN очень просто сделать автоматическое проставление номера версии в билде. В DCVS с этим был гемморой, не знаю как сейчас… То же самое, если нужна связка номеров версий с багтрекером или вики системой.
В локальном репозитории, в который не совершаются коммиты, интовый номер head ревизии будет совпадать с номером head удаленного, из которого был сделан клон. Тоесть, после синхронизации репозиториев билдсервера с центральным репо, номера head ревизий будут совпадать. Не очень очевидно, и красиво, но проблем не вызывает. Девелопер делает пуш, сразу же получает email нотификейшен о коммите, из письма копирует номерок(удаленного репо) и использует его на багтрекере. Или же можно зайти через hgweb и там его посмотреть.
1)гораздо больший шанс того, что в репозитории лежат актуальные результаты работы всех разработчиков. Если разрешить DCVS, то разработчиков сложнее контроллировать.
Не совсем понимаю, в чем тут отличие от DCVS? У нас в конторе например принято делать пуш по окончании выполнения задачи(пофиксил багу, заимплементил фичу, зарефакторил код), также часто девелоперы при работе в группах, синхронизируют друг с другом свои локальные репозитории, минуя центральный(дабы не ломать билд неотлаженным кодом). Вот и получается, что на центральном сервере всегда находятся актуальные результаты работы всех девелоперов. Контролировать тут несложно — пока нет коммита в центральном репо- нет результата работы.
Я не понимаю, почему не упоминается момент, когда нужно анализировать существующий код проекта из тысяч классов, написанный сотней разработчиков разного уровня подготовки? Как насчет рефакторинга в таких условиях? Конечно, можно обойтись простым «Search+Replace», но на эту обезъяью работу уйдет уйма времени. И как раз нежелание делать обезъянью работу будет сдерживать девелоперов заниматься рефакторингом. Так что камень в огород Resharper-a не зачтен.
В последней версии tortoiseHg все эти недостатки исправно отсутствуют и фичи прекрасно работают.
Скажите это тысячам девелоперов которые хостятся на gihub. Конечно, я не буду коммитить в опенсурс проект свои локальные доработки, если они никому не нужны, кроме меня. А если все ок, то без проблем сделаю Pull request.
При разработке коммерческого проекта такое исключено, иначе уволят вмиг.
Разве это проблема, поднять сервер hg и сказать чтоб все туда пушились по завершению работы? У нас именно так и произошло, 4 года — полет отличный.
В локальном репозитории, в который не совершаются коммиты, интовый номер head ревизии будет совпадать с номером head удаленного, из которого был сделан клон. Тоесть, после синхронизации репозиториев билдсервера с центральным репо, номера head ревизий будут совпадать. Не очень очевидно, и красиво, но проблем не вызывает. Девелопер делает пуш, сразу же получает email нотификейшен о коммите, из письма копирует номерок(удаленного репо) и использует его на багтрекере. Или же можно зайти через hgweb и там его посмотреть.
Не совсем понимаю, в чем тут отличие от DCVS? У нас в конторе например принято делать пуш по окончании выполнения задачи(пофиксил багу, заимплементил фичу, зарефакторил код), также часто девелоперы при работе в группах, синхронизируют друг с другом свои локальные репозитории, минуя центральный(дабы не ломать билд неотлаженным кодом). Вот и получается, что на центральном сервере всегда находятся актуальные результаты работы всех девелоперов. Контролировать тут несложно — пока нет коммита в центральном репо- нет результата работы.
Пару месяцев назад использовал tortoiseGit и могу с уверенностью сказать что он убог против последней версии TortoiseHg.