Имхо, в доке сказано, что each работает для array-like объектов, а не просто объектов. А вы попытались подсунуть незнамо что с пропертью lenght. Отсюда duck-typing и не сработал.
Это похоже на баг, потому что раньше вроде один раз поднял — и все, задизаблилась кнопка. Дробная часть появляется тогда, когда двое поднимают друг другу.
Еще интересно, то, что количество голосов за карму из фразы «У вас <...> голосов за карму,» убывает не на единицу при голосовании. При чем, по-моему, что на первое, что на второе нажатие.
Короче, имхо, вид код-ревью процесса в том техническом исполнении оптимален, в котором я его описал на протяжении нашей дискуссии и тут:
Но самое главное, по чему я бы скучал: я склоняюсь к мнению, что неотревьюиные таски не должны бы лежать в центральном репо. Поэтому, было бы прикольно иметь некий промежуточный центральный репо, или его прокси, с интерфейсом для код ревью тула, где можно было бы жать кнопку типа «Review done» и это все переносилось бы в центральный репо от имени автора.
Вроде как crucible такое позволяет делать через патчи, но это несколько далеко от идеала.
Потому как на практике разработчик часто работает одновременно более, чем над одной задачей
Ребята в кедах и на маках расскажут вам, что под каждую задачу создается ветка в гите. Поэтому опеределить поменяные файлы в ветке — не есть сложная задача.
CodeCollaborator так не может.
Этот тул можно допилить. Кстати, где он? Нам просто похвастались?
Она детектирует «измененные файлы» по состоянию «uncommited» в VCS
Если кстати VCS — git и состояние uncommitted смотрится в локальном репо (что по анологии с языком гита будет unpushed), то можно тем самым сэмулировать этот «прокси репозиторий». Тогда можно получить полный список непокомиченных файлов по таске. Это я так гадаю.
Во-первых, я не считаю что в задаче может быть 2 десятка коммитов. Мое твердое убеждение, что 5 — это максимум того что может быть в центральном репозитории, и это если разделилась на подзадачи.
Во-вторых, даже если скажем там n-комитов, то в при использовании описанного тула я бы делал так:
— посмотрел какие файлы поменяны в ревизиях [x1, x2, x3-xM, ..., xY] (те которые относятся к комитам по задаче)
— все эти файлы добавил на ревью/в ревью таску.
Но самое главное, по чему я бы скучал: я склоняюсь к мнению, что неотревьюиные таски не должны бы лежать в центральном репо. Поэтому, было бы прикольно иметь некий промежуточный центральный репо, или его прокси, с интерфейсом для код ревью тула, где можно было бы жать кнопку типа «Review done» и это все переносилось бы в центральный репо от имени автора.
Сейчас сюда напротив сядет такой же и будет «Добрый вечер».
Я понимаю, что вы, наверное это знаете, просто для истории здесь оставлю ;)
Короче, имхо, вид код-ревью процесса в том техническом исполнении оптимален, в котором я его описал на протяжении нашей дискуссии и тут:
Вроде как crucible такое позволяет делать через патчи, но это несколько далеко от идеала.
Как мне рассказывали, там немного.
Ребята в кедах и на маках расскажут вам, что под каждую задачу создается ветка в гите. Поэтому опеределить поменяные файлы в ветке — не есть сложная задача.
Этот тул можно допилить. Кстати, где он? Нам просто похвастались?
Я собрался смотреть дифы закомиченного в локальный репо, но еще незапушеного в центральный.
Если кстати VCS — git и состояние uncommitted смотрится в локальном репо (что по анологии с языком гита будет unpushed), то можно тем самым сэмулировать этот «прокси репозиторий». Тогда можно получить полный список непокомиченных файлов по таске. Это я так гадаю.
Во-вторых, даже если скажем там n-комитов, то в при использовании описанного тула я бы делал так:
— посмотрел какие файлы поменяны в ревизиях [x1, x2, x3-xM, ..., xY] (те которые относятся к комитам по задаче)
— все эти файлы добавил на ревью/в ревью таску.
Но самое главное, по чему я бы скучал: я склоняюсь к мнению, что неотревьюиные таски не должны бы лежать в центральном репо. Поэтому, было бы прикольно иметь некий промежуточный центральный репо, или его прокси, с интерфейсом для код ревью тула, где можно было бы жать кнопку типа «Review done» и это все переносилось бы в центральный репо от имени автора.