Если пользовать VCS, бэкапы вообще не особо нужны. ;)
Хранение и просмотр изменений — непосредственная задача VCS. Пытаться адаптировать под это бэкапы — костыль и жевание кактуса. Делать по новому бэкапу с чейнджлогом на каждое мелкое изменение — какая-то глупость, а для VCS (кроме SVN, я так понимаю, лол) совершенно нормальная и очень полезная практика. И для VCS никакой графики выпиливать не надо.)
примерно год. За это время накопилось 40 бэкапов
В то время как сделать 40 коммитов к гите дело нескольких дней — история получается в разы подробнее, а откатывать отдельные изменения в случае чего (да, их иногда приходится откатывать) гораздо проще.
пока код знаешь хорошо
Вы тоже из тех, кто способен помнить старые крупные проекты годами? Ох, вас уже целых двое.
Вот буквально вчерашний пример. Откопал сайт, к которому не прикасался год. Делал его я один, соответственно никакой удалённый репозиторий ради командной разработки не был нужен. Откопал, потому что заметил, что один пункт меню пропал (не слишком важный пункт, поэтому целый год никто ничего не замечал). Открываю nav.html — нету пункта. При этом я точно помню, что этот пункт раньше был. Соответственно, логично захотелось посмотреть, каким nav.html был раньше.
Что бы было, если бы были только бэкапы? Да ничего. Народ обычно удаляет старые версии бэкапов (особенно через целый год-то), вот и я бы тоже удалил всё старое и оставил бы только последний актуальный бэкап. Но предположим, все старые бэкапы есть — и как бы я в них искал, когда пропал пункт меню из nav.html? Сидеть распаковывать десятки-сотни архивов и смотреть содержимое nav.html в каждом? Данунафиг блин.
Но зато у меня есть локальный репозиторий git! Простейший git log nav.html — и вот я уже вижу все изменения этого конкретного файла. Не прошло и минуты, а я уже нашёл коммит, в котором пункт меню пропал. 4 апреля 2016, описание «Rewrite nav.html». Всё стало ясно: отрефакторил файлик, а пункт меню просто забыл добавить и не заметил. В итоге я просто скопировал пункт меню из старого nav.html в новый, не пришлось писать ни строчки нового кода. git add nav.html && git commit -m 'Restored some nav items'
Пример примитивный, но ничего не мешает случиться чему-нибудь аналогичному на более глобальных изменениях, вроде выпиливания большой фичи, которую внезапно понадобится вернуть. Бэкапы — не замена контролю версий, контроль версий — не замена бэкапам. Если вы способны помнить всё, что делали во всех своих проектах, к которых не прикасались годами — поздравляю, у вас на удивление хорошая память, такая очень мало у кого есть :) А я помнить не только не могу, но и не хочу: зачем, если помнить за меня может обладающий бесперебойной памятью git, причём не требуя удалённого репозитория?) А крутить в голове я лучше буду те проекты, которыми занимаюсь в настоящий момент, а вышеупомянутый сайт к ним не относится.
С VCS надо куда-то выгружать данные
О чём тут речь? В моём случае кроме git add и git commit я ничего не делал, а просмотреть всё могу как простым git log, так и каким-нибудь графическим gitk
Однажды юзер альт-табнется в перекрытое окно, и тут битмап сильно поможет: без него все эти тяжёлые векторы начнут перерисовываться с нуля, и первое, что увидит юзер — не вектор, а серое окно, которое будет оставаться серым, пока вектор не отрисуется — такое часто можно было наблюдать в каких-нибудь WinXP или любых иксах без композитинга. Если же битмап с готовым вектором будет, то он отобразится сразу, что сильно повышает юзерфрендли. Плюс к этому если верхнее окно двигать поверх нижнего окна, то за окном будет оставаться серый след (или в запущенных случаях след из содержимого окна), так как нижнее окно будет не успевать перерисовываться. Лично мне не жалко небольшой нагрузки на проц и память ради того, чтобы подобного не происходило.
А держать запущенное видео в фоне вообще не надо, такое окно стоит хотя бы свернуть)
А т.н. «синдрома отказа от кофе» не случалось? А то я как-то пил кофе каждый день, решил отказаться, а после суток без кофе начинала дичайше болеть голова, которая проходила через 10-20 минут после того как я кофе таки выпью
Хех, на 3G с пингом 60-100 мс и правда тормознутенько, но жить можно. А провод с пингом до 10 мс уже вполне юзабелен и даже в гимпе что-то порисовать можно (хотя кисточка иногда отстаёт, наверно из-за скорости всего мегабит)
Ну не знаю, я тоже вполне логично думал что скорость важна, однако скроллинг в gtk-приложниях абсолютно плавный даже на сетях меньше мегабита и evince рисует пдфки тоже шустро (хотя ощутимо медленнее чем на локалхосте, но на юзабельности не сказывается)
Через что-то с низким пингом, уже не помню точно. Иксы — они такие, скорость им почти не важна, зато важен низкий пинг, иначе начинает слоупочить (в частности, скорость прокрутки в sublime text через сеть ниже чем на локалхосте)
Именно GTK-приложения и запускал, да. Как GTK2, так и GTK3 — все летали. А вот Qt подлагивал, но, к счастью, большинство используемых мной программ используют нелагающий GTK)
Сетевая прозрачность X. Да, это было-было, но прошло
Ну не знаю, ещё в прошлом году активно тыкал проброс иксов через ssh — отлично работает, скорость быстрая, прокрутка плавная, лагов нет, ни в какое сравнение с тормознутым vnc — и из-за этого отсутствие сетевой прозрачности в wayland меня сильно печалит
Такие вещи делают не на «домашнем сервере», а в каких-нибудь амазоновских облаках за небольшую (вроде) плату. А там это займёт всего 2-3 недели)
Если пользовать VCS, бэкапы вообще не особо нужны. ;)Хранение и просмотр изменений — непосредственная задача VCS. Пытаться адаптировать под это бэкапы — костыль и жевание кактуса. Делать по новому бэкапу с чейнджлогом на каждое мелкое изменение — какая-то глупость, а для VCS (кроме SVN, я так понимаю, лол) совершенно нормальная и очень полезная практика. И для VCS никакой графики выпиливать не надо.)
В то время как сделать 40 коммитов к гите дело нескольких дней — история получается в разы подробнее, а откатывать отдельные изменения в случае чего (да, их иногда приходится откатывать) гораздо проще.
Вы тоже из тех, кто способен помнить старые крупные проекты годами? Ох, вас уже целых двое.
Что ж, поздравляю, вы уникальный :) Мне (и, думаю, многим другим) в первую очередь нужны и важны именно логи.
Даже спустя год? И храните все столь старые бэкапы? Вы всё ещё уникальный, можете гордиться этим))
Вот буквально вчерашний пример. Откопал сайт, к которому не прикасался год. Делал его я один, соответственно никакой удалённый репозиторий ради командной разработки не был нужен. Откопал, потому что заметил, что один пункт меню пропал (не слишком важный пункт, поэтому целый год никто ничего не замечал). Открываю nav.html — нету пункта. При этом я точно помню, что этот пункт раньше был. Соответственно, логично захотелось посмотреть, каким nav.html был раньше.
Что бы было, если бы были только бэкапы? Да ничего. Народ обычно удаляет старые версии бэкапов (особенно через целый год-то), вот и я бы тоже удалил всё старое и оставил бы только последний актуальный бэкап. Но предположим, все старые бэкапы есть — и как бы я в них искал, когда пропал пункт меню из nav.html? Сидеть распаковывать десятки-сотни архивов и смотреть содержимое nav.html в каждом? Данунафиг блин.
Но зато у меня есть локальный репозиторий git! Простейший
git log nav.html— и вот я уже вижу все изменения этого конкретного файла. Не прошло и минуты, а я уже нашёл коммит, в котором пункт меню пропал. 4 апреля 2016, описание «Rewrite nav.html». Всё стало ясно: отрефакторил файлик, а пункт меню просто забыл добавить и не заметил. В итоге я просто скопировал пункт меню из старого nav.html в новый, не пришлось писать ни строчки нового кода.git add nav.html && git commit -m 'Restored some nav items'Пример примитивный, но ничего не мешает случиться чему-нибудь аналогичному на более глобальных изменениях, вроде выпиливания большой фичи, которую внезапно понадобится вернуть. Бэкапы — не замена контролю версий, контроль версий — не замена бэкапам. Если вы способны помнить всё, что делали во всех своих проектах, к которых не прикасались годами — поздравляю, у вас на удивление хорошая память, такая очень мало у кого есть :) А я помнить не только не могу, но и не хочу: зачем, если помнить за меня может обладающий бесперебойной памятью git, причём не требуя удалённого репозитория?) А крутить в голове я лучше буду те проекты, которыми занимаюсь в настоящий момент, а вышеупомянутый сайт к ним не относится.
О чём тут речь? В моём случае кроме
git addиgit commitя ничего не делал, а просмотреть всё могу как простымgit log, так и каким-нибудь графическимgitkОднажды юзер альт-табнется в перекрытое окно, и тут битмап сильно поможет: без него все эти тяжёлые векторы начнут перерисовываться с нуля, и первое, что увидит юзер — не вектор, а серое окно, которое будет оставаться серым, пока вектор не отрисуется — такое часто можно было наблюдать в каких-нибудь WinXP или любых иксах без композитинга. Если же битмап с готовым вектором будет, то он отобразится сразу, что сильно повышает юзерфрендли. Плюс к этому если верхнее окно двигать поверх нижнего окна, то за окном будет оставаться серый след (или в запущенных случаях след из содержимого окна), так как нижнее окно будет не успевать перерисовываться. Лично мне не жалко небольшой нагрузки на проц и память ради того, чтобы подобного не происходило.
А держать запущенное видео в фоне вообще не надо, такое окно стоит хотя бы свернуть)
Есть опасение, что тех, кто тупо копипастит решения, всё-таки гораздо больше (правда, хз как это проверить)
А т.н. «синдрома отказа от кофе» не случалось? А то я как-то пил кофе каждый день, решил отказаться, а после суток без кофе начинала дичайше болеть голова, которая проходила через 10-20 минут после того как я кофе таки выпью
Хех, на 3G с пингом 60-100 мс и правда тормознутенько, но жить можно. А провод с пингом до 10 мс уже вполне юзабелен и даже в гимпе что-то порисовать можно (хотя кисточка иногда отстаёт, наверно из-за скорости всего мегабит)
Ну я субъективно наблюдал 60фпс, и мысли не было о том что это может быть некомфортным) Завтра попутно видео запишу, там кадры посчитаю
Завтра попробую повторить на чём-нибудь медленном
Моих знаний не хватит чтобы это проверить, я простой юзер)
В районе 20-40 мс пинг был вроде
Ну не знаю, я тоже вполне логично думал что скорость важна, однако скроллинг в gtk-приложниях абсолютно плавный даже на сетях меньше мегабита и evince рисует пдфки тоже шустро (хотя ощутимо медленнее чем на локалхосте, но на юзабельности не сказывается)
Через что-то с низким пингом, уже не помню точно. Иксы — они такие, скорость им почти не важна, зато важен низкий пинг, иначе начинает слоупочить (в частности, скорость прокрутки в sublime text через сеть ниже чем на локалхосте)
Именно GTK-приложения и запускал, да. Как GTK2, так и GTK3 — все летали. А вот Qt подлагивал, но, к счастью, большинство используемых мной программ используют нелагающий GTK)
Ну не знаю, ещё в прошлом году активно тыкал проброс иксов через ssh — отлично работает, скорость быстрая, прокрутка плавная, лагов нет, ни в какое сравнение с тормознутым vnc — и из-за этого отсутствие сетевой прозрачности в wayland меня сильно печалит
Всё намного проще)
Не знаю, у меня нет приватных репозиториев чтобы проверить) Но подозреваю, что всё-таки просто календарь рисует
Обычно жалуются на меньший FPS и/или качество графики хуже чем в windows-версии