R
Тут какой-то особенный инструмент нужен
Size: a a a
2020 March 12
S
В конце концов можно использовать две системы. Одна для картинок, другая для исходников. Не вижу проблемы.
R
В конце концов можно использовать две системы. Одна для картинок, другая для исходников. Не вижу проблемы.
Мне кажется, именно нужно, а не можно.
S
Мне кажется, именно нужно, а не можно.
Некоторые же любят создавать себе проблемы. Мало ли.
R
Гит хорош для текстовых данных, а для пикч надо что-то совершенно особенное
CU
Некоторые же любят создавать себе проблемы. Мало ли.
Например проблему использования двух СКВ и путаница с ними
R
Например проблему использования двух СКВ и путаница с ними
Используйте подходящие инструменты для соответствующих задач, ну.
R
Если СКВ для пикч и с исходниками будет справляться прекрано — тогда можно и одну СКВ оставить. Но гит для пикч — это неудачный выбор инструмента.
eb
Например проблему использования двух СКВ и путаница с ними
Ну да, лучше конечно сотнями мегабайт выкачивать чуть не каждый дизайнерский штришок кистью.
CU
Ну да, лучше конечно сотнями мегабайт выкачивать чуть не каждый дизайнерский штришок кистью.
Ну либо не сопоставлять когда какие изменения пришли, если нужно откатывать что-то, как ты это сделаешь? А слитие как происходит будет? А как дизайнеров научить использовать две СКВ одновременно?
Слишком опасно
Слишком опасно
eb
Гит хорош для текстовых данных, а для пикч надо что-то совершенно особенное
Вот кстати справидливости ради, есть же всякие svg'шки, да и многие форматы 3d это текст..
Но оно конечно скорее исключения, нежели правило.
Но оно конечно скорее исключения, нежели правило.
R
Вот кстати справидливости ради, есть же всякие svg'шки, да и многие форматы 3d это текст..
Но оно конечно скорее исключения, нежели правило.
Но оно конечно скорее исключения, нежели правило.
Да, оно понятно, но импакт мелких изменений может быть такой, что дифф будет больше чем исходная пикча
TG
перфорс для данных, гит для кода
CU
перфорс для данных, гит для кода
Как сопоставлять изменения данных и коммиты с ветками в коде?
TG
бранчиться по данным обычно не нужно, шелвы удобны.
R
перфорс для данных, гит для кода
перфорс дорогой
TG
Как сопоставлять изменения данных и коммиты с ветками в коде?
заливать вместе с кодом
TG
перфорс дорогой
время дороже
eb
Ну либо не сопоставлять когда какие изменения пришли, если нужно откатывать что-то, как ты это сделаешь? А слитие как происходит будет? А как дизайнеров научить использовать две СКВ одновременно?
Слишком опасно
Слишком опасно
Ну один фиг, мне кажется для контента нужно отдельное от кода хранилище.
Другое дело что граница размыта. Например не понятно что такое json сцена.. Вроде контент, а вроде и дифы будут адекватно считаться.
Нужно исходить из кол-ва и "дороговизны" условных коммитов, и принимать соответствующие скв и правила их использования.
"Простого" решения тут нет.
Другое дело что граница размыта. Например не понятно что такое json сцена.. Вроде контент, а вроде и дифы будут адекватно считаться.
Нужно исходить из кол-ва и "дороговизны" условных коммитов, и принимать соответствующие скв и правила их использования.
"Простого" решения тут нет.
CU
Ну один фиг, мне кажется для контента нужно отдельное от кода хранилище.
Другое дело что граница размыта. Например не понятно что такое json сцена.. Вроде контент, а вроде и дифы будут адекватно считаться.
Нужно исходить из кол-ва и "дороговизны" условных коммитов, и принимать соответствующие скв и правила их использования.
"Простого" решения тут нет.
Другое дело что граница размыта. Например не понятно что такое json сцена.. Вроде контент, а вроде и дифы будут адекватно считаться.
Нужно исходить из кол-ва и "дороговизны" условных коммитов, и принимать соответствующие скв и правила их использования.
"Простого" решения тут нет.
На занимаемый объём насрать, мне важно сократить время работы без того чтобы дизайнерам пришлось учиться работать с СКВ заново, да и минимизировать человеческий фактор