Синхронизация кода на разных машинах

Sergiy Borodych Developer 14.11.2014 16:18

Можете спробувати ще syncthing (pulse)
github.com/...thing/syncthing

Якщо git здається занадто складним для такої задачі.

anonymous 08.11.2014 18:41

GitHub или Assembla

Dmitriy Levin Android developer 08.11.2014 13:01

Один аккаунт на dropbox на ПК и на нотике с маркой Projects решает данный вопрос весьма успешно, больше года пользуюсь такой фичей.
Это удобно, можно продолжить работу с того же места, допустим на ноутбуке (не забыв в эклипсе обновить папку проекта по F5)
P.S. Ну и конечно для надежности систему контроля версий никто не отменял, не забудьте завести Git в Ваш проект.

Nick 08.11.2014 01:07

GitHub, Bitbucket.
Если все плохо — воркспейс в дропбокс

Andrew Sevastianov 07.11.2014 19:58

Я собі завів хостинг для цієї потреби. git + redmine

anonymous 08.11.2014 12:59

-

Denys Karpov SE 07.11.2014 17:33

try.github.io

Олександр Зайцев Android Engineer 07.11.2014 17:11

Хочешь, чтобы другие видели твой проект — Github. Если «моя прелесть» — Bitbucket. В последнем бесплатно в одной команде может быть 5 человек.

Андрей Литвинов C Señor 08.11.2014 11:40

Кстати, Bitbucket good еще и потому, что там можно Mercurial использовать, а не только Git.

Олександр Зайцев

Gennady Dogaev full-stack web developer (freelance) 07.11.2014 15:54

Git (кажется, можно внутри сети клонировать ветку напрямую, но я не пробовал), GitHub, GitLab (если есть какой-нибудь сервер дома или желание купить VPS)

Владимир Кожаев 07.11.2014 14:59

Это называется системы контроля версий. Гугли и да прибудет с тобою сила

Volodymyr Spodaryk Software Engineer 07.11.2014 14:50

Якщо працюєш сам: Google Drive, Dropbox
Якщо в команді: Bitbucket, GitHub
Все решта, на власний смак)

Java Adept 07.11.2014 17:27

Якщо працюєш сам: Google Drive, Dropbox

Месье знает толк в извращениях

Volodymyr Spodaryk

Євген Козлов Front-end developer в SoftServe 08.11.2014 00:26

ну-ну. а коммитить и пушить заведомо нерабочий код, бо «пора домой, так и закончу» — это как называется?
а закидывать файл настроек и файл с историей выполнения команд в репозиторий ради удобной синхронизации — это норм?

Java Adept

Java Adept 08.11.2014 00:36

ну-ну. а коммитить и пушить заведомо нерабочий код, бо «пора домой, так и закончу» — это как называется?

CI нету?

Євген Козлов Front-end developer в SoftServe 08.11.2014 00:51

причем тут CI? вот, недописал я код. хочу продолжить дома.
коммичу неполноценный код, запускается билд, который валится — об этом речь? и как это помогает?
а как же история изменений — с «половинными» коммитами? или amend/rebase наше всё?
я как-то краем глаза слышал про «атомарность изменений» и «работоспособность кода», как требования к коммитам. по-моему, довольно здраво.

Java Adept

anonymous 08.11.2014 01:18

-

Jo E 08.11.2014 01:26

Branching?

Євген Козлов Front-end developer в SoftServe 08.11.2014 01:56

спецбранча «а тут обкусанные коммиты»? :)

Jo E

Jo E 08.11.2014 02:54

Створюй свій власний бранч із блекджеком і дамами і вперед. Крім того, я маю сумніви щодо того, що замовник буде радий факту заливки коду на дропбокс чи будь-куди (навіть синхронізація через VCS на домашній комп/ноут сумнівна). На додачу, наскільки великий репозиторій? Репозиторій може бути дуже великим, і твій код не буде працювати без залежностей. Їх також заливати?

Як на мене, то варіант «залий на Дропбокс код із роботи щоб попрацювати» дуже малоймовірний. От для персонального проекту — можливо. Але я все одно віддаю перевагу GitHub, Visual Studio Online or Bitbucket

Євген Козлов Front-end developer в SoftServe 08.11.2014 08:48

Крім того, я маю сумніви щодо того, що замовник буде радий факту заливки коду на дропбокс чи будь-куди (навіть синхронізація через VCS на домашній комп/ноут сумнівна)

в таком случае, чем github секьюрнее? только VPN + remote control на рабочую станцию.

На додачу, наскільки великий репозиторій? Репозиторій може бути дуже великим, і твій код не буде працювати без залежностей. Їх також заливати?

мы говорим вообще или про конкретные кейсы?
если про конкретные кейсы, то в принципе, считаю, депенденси должны быть вне репозитория(для чего ставится менеджер депенденси, специфический для целевого языка). или в отдельном репозитории вообще. исходя из того, что депенденси меняются, ну, оооочень редко, в сравнении с основным кодом проекта

Jo E

Андрей Литвинов C Señor 08.11.2014 11:44

депенденси меняются, ну, оооочень редко

Только бывает выходят новые версии зависимойстей. И довольно часто.

Євген Козлов Front-end developer в SoftServe 08.11.2014 14:03

если вы не глядя запускаете обновление депенденси, без объемного(из-за основательности) регрешна(автоматического или ручного, а лучше — и того, и того), каждый раз, как выходит новая версия — у меня для вас плохие новости.
и да, под «изменениями» я имел в виду именно апдейты, а не «выкинем все библиотеки и возьмем за основу другие»

Андрей Литвинов

Андрей Литвинов C Señor 08.11.2014 14:44

Нет, конечно же, я не имел в виду подход пыщ-пыщ и в продакшен. Но в своем проекте я страюсь спользовать самые свежие версии внешних компонент. И использую при этом менеджер зависимойстей, как вы и описали. И все они подтягиваются при сборке проекта, если чего-то не хватает.

Євген Козлов Front-end developer в SoftServe 09.11.2014 11:55

ну? зачем в таком случае включать депенденси в репозиторий? :)
включается только конфиг, так же?

Андрей Литвинов

Андрей Литвинов C Señor 09.11.2014 12:44

включается только конфиг, так же?

Да, все верно. Я не пытался сказать, что зависимости нужно включать в репозиторий, наоборот. Возможно был неправильно понят :).

Ivan M Software Engineer в Лідер ринку 08.11.2014 03:31

вот, недописал я код. хочу продолжить дома.

RDP спасет отца русской демократии :) Нечего чужой код на домашний комп копировать)

Євген Козлов Front-end developer в SoftServe 08.11.2014 08:50

Нечего чужой код на домашний комп копировать)

it depends.
кое-где даже RDP запрещено(ну, заблокировано) по причине паранойи. обоснованной или дутой — то уже отдельный вопрос.
если охота обсудить вопросы безопасности применительно к абстрактному проекту с неизвестными policy — это без меня.

Ivan M

Java Adept 10.11.2014 23:49

Нечего чужой код на домашний комп копировать)

Кому интересны фиксы индийских удобрений?

Ivan M

Ivan M Software Engineer в Лідер ринку 11.11.2014 01:33

Очень жаль что вам приходится работать с «фиксами индийских удобрений» :)

Java Adept

Valentin Nechayev уповноважений по милицях в Дарницькі печери 08.11.2014 09:46

я как-то краем глаза слышал про «атомарность изменений» и «работоспособность кода», как требования к коммитам. по-моему, довольно здраво.

Реально это не так, особенно в случае рабочих веток git, ибо
1) в некоторых случаях он заставляет коммитить временное — когда из stash’а идут изменения на тот же файл, что уже локально изменён — соответственно, git add $file; git commit -m tmp
2) за счёт переформатирования коммитов через interactive rebase в своих ветках можно коммитить любую ерунду, главное, чтобы потом оформить её уже _публично_ в виде аккуратной связной цепочки

Євген Козлов Front-end developer в SoftServe 08.11.2014 11:18

2) за счёт переформатирования коммитов через interactive rebase

не-а. «благодаря возможности править историю, можно локально коммитить всякий калл». бардак не должен быть частью рабочего процесса.

1) в некоторых случаях он заставляет коммитить временное — когда из stash’а идут изменения на тот же файл, что уже локально изменён — соответственно, git add $file; git commit -m tmp

опять же, после этого вы этот коммит пушите? или откатываете, чтоб в коммит не попало что-то полурабочее?

вы сейчас выдаете исключительные ситуации за правило.
впрочем, я кажется понял:

чтобы потом оформить её уже _публично_ в виде аккуратной связной цепочки

речь о push и локальных коммитах, верно?
а теперь, скажите, к теме топика: если мы используем github для синхронизации кода между разными машинами, придется ли нам пушить(т.е. «публиковать») полурабочий коммит с частью изменений? или локальный коммит на одной машине магическим образом перетечет на другую, где мы сможем доработать его и запушить?

Valentin Nechayev уповноважений по милицях в Дарницькі печери 10.11.2014 15:47

«благодаря возможности править историю, можно локально коммитить всякий калл». бардак не должен быть частью рабочего процесса.

А программисты должны с первого раза без ошибок писать идеальный код, который пойдёт сразу в продакшн космического масштаба. И никаких багов и их лечений, бардак не должен быть частью рабочего процесса. Сделавшего одну ошибку — на кол, весь его код — сжечь комиссией из 12 первосвященников.

опять же, после этого вы этот коммит пушите?

Нет.

или откатываете, чтоб в коммит не попало что-то полурабочее?

Обычно удобнее всего откатить. Но во многих случаях удобнее, наоборот, докатить (добавить нужные файлы и сделать commit —amend с доведением сообщения коммита до пригодного публично).

вы сейчас выдаете исключительные ситуации за правило.

Ничего подобного. Можно делать так, что это будет только исключительной ситуацией. А можно автоматически коммитить каждую минуту и потом объединять сделанное во внятные цепочки. Сила инструмента не в том, как он сам работает, а в том, что он позволяет.

придется ли нам пушить(т.е. «публиковать») полурабочий коммит с частью изменений?

Можно пушить, а можно и нет. Вариант, что я имел в виду — запушить это в персональную ветку данного автора (или даже персональное репо), главное, что не в основное разделяемое — там всем этим временным состояниям действительно делать нечего.

Євген Козлов Front-end developer в SoftServe 10.11.2014 16:40

Можно пушить, а можно и нет

и как без пуша это будет доступно на другой машине?

Valentin Nechayev уповноважений по милицях в Дарницькі печери 10.11.2014 16:53

и как без пуша это будет доступно на другой машине?

Любыми другими методами:) Но push в свою ветку — один из простых удобных методов.

Sergiy Borodych Developer 14.11.2014 12:53

милом патч відправляти ;)
git під це добре теж заточений :)

Євген Козлов Front-end developer в SoftServe 14.11.2014 13:41

ставим git
недорабочий код формируем в патч
высылаем себе на мыло
на другой машине накатываем патч
результат доработки опять формируем в патч
и высылаем себе на мыло

я ничего не пропустил?

Sergiy Borodych

Sergiy Borodych Developer 14.11.2014 14:33

все правильно, тільки то все ж я пошуткував :)
до речі, кількість пунктів можна скоротити/автомазитувати (за допомогою тих же bash/git alias, mail forward, etc)
+ є ще така штука як git bundle ;)

але якщо серейозно, то я наприклад користуюсь (дещо вже зазначали вище):
— окрема «своя» гілка (рідко)
— окремий «свій» репо
— direct push/fetch на/з потрібну машину (часто), хоча тут потрібен прямий зв’язок

Євген Козлов Front-end developer в SoftServe 14.11.2014 15:32

до речі, кількість пунктів можна скоротити/автомазитувати (за допомогою тих же bash/git alias, mail forward, etc)

или дропбокс :)
правда, там все же есть один недостаток — нет ничего типа .gitignore, и будет синкаться все подряд :(

Sergiy Borodych

Sergiy Borodych Developer 14.11.2014 16:12

BTW спробуйте syncthing AKA pulse (now)
вже на стадії “можна юзати”
там є .stignore ;)
да і backup/history

Gennady Dogaev full-stack web developer (freelance) 08.11.2014 14:10

Ветки отдельные для каждого разработчика + merge requests. Не уверен, но кажется что merge даже одним коммитом будет выглядеть

Євген Козлов Front-end developer в SoftServe 08.11.2014 14:40

к чему это вы написали?
merge будет выглядеть либо коммитом, либо вообще никак не будет выглядеть, если fast-forward. но это технические детали.
вы предлагаете использовать бранчи как именованный per-developer stash.
и что это даст? какие достоинства в сравнении с синхронизацией незавершенных изменений через dropbox или bittorrent sync?

Gennady Dogaev full-stack web developer (freelance) 08.11.2014 15:00

к чему это вы написали?

К тому, что проблема коммита незавершенных изменений решаема, причём довольно легко.

и что это даст? какие достоинства в сравнении с синхронизацией незавершенных изменений через dropbox или bittorrent sync?

Нет особой разницы, кому что нравится.

anonymous 08.11.2014 18:49

Для этих ситуаций и были придуманы бранчи. В чём проблема?

Євген Козлов Front-end developer в SoftServe 09.11.2014 11:57

локально — да.
пролистайте выше: речь о синхронизации состояния проекта между разными компами. так что без push’a не реализуемо просто созданием веток.
конечно, разве что вы предлагаете бросить в дропбокс сугубо папку .git, что совсем уже сурово

anonymous

anonymous 08.11.2014 14:44

rsync или ssh agent forwarding

Vladislav Povedyuk Java Developer 07.11.2014 14:22

Github

Andriy Kuba Астронавт в Ciklum 07.11.2014 12:32

я особисто працюю на двох машинах — робота\дім

Код:
bitbucket, github

Документи:
google drive, jira, confluens

Різні дрібниці, пісочниці і т.д:
drupbox, google drive

Спеціальне середовище, наприклад приватний сервер для розробки з відповідними програмами:
vagrant, скрипт якого в bitbucket\github

Nickolay Kondratenko Developer в Svitla 07.11.2014 13:49

я бы ещё добавил evernote

Andriy Kuba

Grez 14.11.2014 16:15

только не гитхаб, а просто гит.

Andriy Kuba

Andrii Serhiienko 07.11.2014 12:27

Не слушай никого кто будет тебе парить github или bitbucket и прочую фигню. Надо архивировать исходники zip или rar и синхронизировать между машинами посредством электронной почты. Самый надежный и проверенный способ.

Oleh 07.11.2014 12:33

5″ дюймовими дискетами, а архіватор arj краще.

Andrii Serhiienko 07.11.2014 12:34

rar жмет лучше arj
а дискеты лучше брать тогда уже 3.5 — они гораздо практичнее

Oleh

Jimini Bilibob 14.11.2014 16:39

7z жмет еще лучше

Andrii Serhiienko 14.11.2014 17:31

Во времена дискет 7z не было. Ты просто юмора не понял.

Jimini Bilibob

Євген Козлов Front-end developer в SoftServe 14.11.2014 18:10

это в 1999 не было-то? :)
я как-то даже работающий дисковод на 5.25″ застал

Andrii Serhiienko 14.11.2014 18:13

в 99-м только первая бета вышла. Так что, да, можно сказать что не было. А причем тут работающий дисковод?

Євген Козлов Front-end developer в SoftServe 15.11.2014 18:31

А причем тут работающий дисковод?

в налоговую реально приносили отчеты на 5.25″ дискетах. чему и был свидетелем.
UPD: ага, понял нюанс. «работающий» — не в смысле «рабочий, работоспособный», а в смысле «используемый»

Andrii Serhiienko 15.11.2014 18:37

Тут явно какой-то misunderstanding. Я не утверждал что в 99-м не было дискет. Я сказал, что в то время, когда дискеты были в ходу — тогда еще не было 7z (это архиватор такой, если что), вышла только его первая бета.

Євген Козлов Front-end developer в SoftServe 15.11.2014 19:00

это я понял. и согласен. плохо помню.
а комментирую только вопрос насчет дисковода на 5.25″

Nickolay Kondratenko Developer в Svitla 07.11.2014 13:38

Хотел предложить флешку, но дискета лучше
Кстати, помню студенческие годы: project project_old project_new project_last project_final.. Кстати, может, именно этот опыт заставляет полюбить системы управления версиями?

Oleh

Vladislav Povedyuk Java Developer 07.11.2014 14:22

!КУРСОВОЙ
!!КУРСОВОЙ
!!!ЗАПИСКА — ПЕЧАТЬ

Весело было же)))

Nickolay Kondratenko

Oleg Kariakin Senior Java Developer 07.11.2014 12:44

Есть еще лучше способ — копировать весь проект, а лучше всю эклипсу сразу между машинами. Также как при переключении на бранчу клонировать репозиторий еще раз в новую папку. :-)

Andrii Serhiienko 07.11.2014 13:10

Вот, тоже отличный метод. Спасибо, товарищ!

Oleg Kariakin

Hnat Kubov 07.11.2014 19:47

Пам’ятаю колись всі лабораторні по Паскалю носилися на дискеті в одному каталозі з TP7.EXE. «Ставь класс єслі тоже так дєлал!»

Oleg Kariakin

Maksym Leonidov Front-end developer в CreatorIQ 07.11.2014 12:45

А чем это удобнее и надежнее использования github или bitbucket ?

Mikhail Boiko SE в NVIDIA 07.11.2014 13:00

Это быстрее, проще и понятнее.

Maksym Leonidov

Andrii Serhiienko 07.11.2014 13:12

Прям девиз из «а-ну-ка, мальчики!»

Mikhail Boiko

Andrii Serhiienko 07.11.2014 13:11

Тем что ваш драгоценный код всегда с вами, а не где-то у проклятых пиндосов с их АНБ. Вы Сноудена читали? Вот почитайте.

Да и, опять же: пушить, контрибутить и вот это всё — это совершенно чуждые понятия, насаждаемые нам госдепом.

Maksym Leonidov

Valentin Nechayev уповноважений по милицях в Дарницькі печери 15.11.2014 12:03

электронной почты

???

email дико неэффективен для дискет, правильно использовать FTN.

Нестор Иванович 07.11.2014 00:26

малчык сюда хады тут рэпозыторый прыватный безплатно дам bitbucket.org

DNA Exp 07.11.2014 00:14

Static IP + Remote desktop

Yury Gavrilenko 07.11.2014 00:19

сударь знает толк ©

DNA Exp

Нестор Иванович 07.11.2014 00:27

у него все так по ходу, не перестает радовать парень

Yury Gavrilenko

DNA Exp 07.11.2014 08:53

Ты прикалываешся ? Это самый удобный способ. На одной тачке один раз всё скачал, установил, настроил. Потом если надо, допустим, поработать с работы, щелк щелк зашел работаешь. Уехал кудато далеко, в гостях у друга, в компьютерном клубе в другой стране, надо поработать. Щелк щелк на чужой машине, зашел работаешь. Не установив не единой левой тулзы на чужой машине, все стандартными средствами. Нужно по внутренней сеточке полазить, чтото кудато переписать. Раз два и готово. Да даже я ехал недавно в поезде, на мобиле установил Remote Desktop, зашел с мобилы на свой комп и тоже посмотрел результаты тестов, поклацал, сервиса кое какие перезапустил.

Постоянно синхронизироваться это изврат. Многие конторы уже давно на облачных хостингах работают.

Нестор Иванович

Hnat Kubov 07.11.2014 19:55

У VCS історія коду зберігається. Легко відкочуватись до попередньої версії, якщо щось поламалось. А ви як цю проблему вирішуєте? FooBar2014-10-07.cpp.backup, а в ньому

/* // Uncomment if something went wrong
void foo() {
...
} */

Хоча це звісно теми прямо не стосується. Але після того, як звикнеш до Git, складно казати, що RDP може бути краще за нього навіть суто для синхронізації.

DNA Exp

DNA Exp 07.11.2014 22:08

git, svn, mercury, vss и прочьи приблуды в основном нужны, когда над проектом работает команда разработчиков. Им нужно синхронизировать исходники, отслеживать кто что менял и тд. Если разработчик один работает над одним проектом, то его польза стремится к нулю. Проще раз настроить ремоут дексктоп и работать с любой точки земного шара где есть интернет. Вплоть до мобильных устройств.
Если работаешь с сложным проектом, то ремоут десктоп просто необходимость. Поскольку кроме исходников, чтобы запустить и чтото протестировать нужно быть внутри удаленной сети, где разные сервера взаимодействуют друг с другом. Настроить это все повторно на домашнем компе это мазохизм высшей степени.

Hnat Kubov

Hnat Kubov 07.11.2014 22:21

Ви кого зараз у цьому хочете переконати? Тих, хто ніколи не використовував системи контролю версій?

Повторюся, я відхилився від теми, бо якщо питання тільки у роботі над одним кодом із різних пристроїв, то можливо ваше рішення і зручніше. Але з git’ом приходять такі можливості, від яких потім не захочеш відмовлятись. Хоча ніхто не заважає й поєднувати. Можна мати локальний git-репозиторій на RDP суто для контролю версій, а не синхронізації.

Навіть якщо розробник один, йому все одно потрібно відстежувати зміни в своєму коді. Без VCS це зазвичай виливається у купу сміттєвих бекап-файлів та простирадла закоментованого коду «про всяк випадок». Був там, знаю. Чи у вас не так?

DNA Exp

DNA Exp 07.11.2014 22:25

Да многие проекты вы просто не запустите без ремоут десктоп. Я приведу пример. У нас был очень слабый канал с заказчиком, чтобы стянуть коследний код через vss, последнюю версию к себе на компьютер, нужно было час курить. Вместе с тем, ремоут десктоп ест реально копейки. Он даже вполне себе сносно работает на мобильных gprs каналах. А такими интернетом покрыта вся Украина, по тарифу гривна в день.

Hnat Kubov

Valentin Nechayev уповноважений по милицях в Дарницькі печери 08.11.2014 09:48

Самое смешное тут — слово vss. Это такое чудо, что даже CVS по сравнению с ним — вершина прогресса.

С полезностью RDP в принципе согласен, но если этот RDP называется ssh+screen :)

DNA Exp

Hnat Kubov 08.11.2014 10:17

Я би у вашій формулі замінив screen на tmux. А для нестабільного grps можна використовувати Mosh (так вони пишуть, сам не користував).

Але логіка пана Booben Com, судячи з усього, прив’язана до OS Windows.

Valentin Nechayev уповноважений по милицях в Дарницькі печери 08.11.2014 10:22

Я би у вашій формулі замінив screen на tmux.

Я попробовал tmux, расплевался и больше не хочу. У него единственное преимущество — более ясный код, функционально же он хуже почти во всём. Может, лет через 5 он будет приличным.

Про Mosh не слышал, посмотрю на досуге.

Але логіка пана Booben Com, судячи з усього, прив’язана до OS Windows.

Ну, часто заказчика и платформу не выбирают. При этом заказчик может и выдвигать требования типа “код в VSS”. Собственную логику таки надо смотреть на собственных проектах.

Hnat Kubov

Dmytro Sirenko SRE 08.11.2014 17:06

функционально же он хуже почти во всём.

— хочу знати більше, тому що, наприклад, вертикальний split у screen досі робиться тільки патчем.

Valentin Nechayev уповноважений по милицях в Дарницькі печери 09.11.2014 15:57

Поставил, посмотрел на свежий. Да, за два года продвинулось — уже есть почти всё, что нужно:) Но вот ряд принципиальных ляпов убивает возможности его использования. У меня местами до 3 уровней вложенности сессий, с разными переключателями. В screen это тривиально — сказал “screen -e^oa” на нужном уровне, и поехал работать. В tmux этот переключатель числится как глобальная опция на уровне сервера (а нахрена???), и начинается дикий изврат.
Не видно force detach, и особенно комбинаций типа -Dr. Для attach нет режима “подцепиться к первой попавшейся сессии данного юзера, или обломиться, если свободных нет”, который очень удобен и который в screen по умолчанию.
Не видно варианта “вместо status line на экране использовать xterm caption”, по умолчанию эта status line включена и жрёт дорогое место.

тому що, наприклад, вертикальний split у screen досі робиться тільки патчем.

Ни разу такое не было нужно.:) Но если нужно — патч легко ищется и доступен.

Dmytro Sirenko

Dmytro Sirenko SRE 09.11.2014 16:51

У меня местами до 3 уровней вложенности сессий, с разными переключателями.

— да, згоден, я не знаю рішення, яке б дозволяло не клацати Ctrl-B кожен раз потрібну кількість разів.

Не видно force detach

— а що таке force detach?

Для attach нет режима “подцепиться к первой попавшейся сессии данного юзера, или обломиться, если свободных нет”

— what? Якщо просто робити `tmux attach`, то буде підключатись перша незаттачена сесія, інакше команда обломиться і заявить про “no tmux server”.

status line включена и жрёт дорогое место

— залежить від розміру термінала; я стараюсь використовувати побільше екранного простору, тому навіть у screen включав status line автоматично, щоб знати, чи я у screen без зайвих команд (а місця мені не жаль).

Ни разу такое не было нужно.:)

— не знаю, не знаю, коли у мене великий термінал (на робочому ${COLUMNS}x${LINES} доходить до 450×60), це життєво важлива фіча. Крім того, я більше люблю panes (ділянки, видимі одночасно), ніж “вкладки”: так видно одразу все без перемикання.

Коротше, я зрозумів, що кожному свої юзкейси, і що tmux краще для великих екранів, а screen на класичному 80×25.

Мені ще в tmux не подобаються дефолтні клавіші, і я також люблю перемикання по Ctrl-A і h/j/k/l між panes, але це лікується елементарно.

Valentin Nechayev уповноважений по милицях в Дарницькі печери 09.11.2014 21:10

— а що таке force detach?

Это с попыткой завершения родителя для клиентского процесса.

— what? Якщо просто робити `tmux attach`, то буде підключатись перша незаттачена сесія, інакше команда обломиться і заявить про “no tmux server”.

1. В мане этого не описано, или описано как-то невнятно. 2. А почему “no tmux server”, что за нелепая диагностика?

і що tmux краще для великих екранів, а screen на класичному 80×25.

Вполне возможно. Хотя я и на больших, если бывают, предпочитаю screen:)

і я також люблю перемикання по Ctrl-A і h/j/k/l між panes, але це лікується елементарно.

Ctrl+A это диверсия, а насчёт “элементарно” сами выше признались, что это в удобном варианте невозможно.

Dmytro Sirenko

anonymous 08.11.2014 08:39

-

DNA Exp

Євген Козлов Front-end developer в SoftServe 08.11.2014 08:54

Если разработчик один работает над одним проектом, то его польза стремится к нулю. Проще раз настроить ремоут дексктоп и работать с любой точки земного шара где есть интернет. Вплоть до мобильных устройств.

одно другому не мешает.
репозиторий делать доступным через интернет, действительно, не обязательно в таком случае. но он, репозиторий, все равно несет офигенную пользу.
1. создает историю — и позволяет вернуться к коду на какую-то дату.
2. структурирует историю — правки сгруппированны по смыслу(а не как в бекапе), в идеале сопровождаются датой правки и комментом.
3. добавляет возможностей по мониторингу проекта — и поддержанию его здоровья. всякие там хуки с проверками на закоммиченные дебаг-конструкции сэкономят время и нервы. например.
4. ветки позволять переключаться между кодом по незавершенным задачам(вот, здесь, без репо вообще не разрулиться)

DNA Exp

Valentin Nechayev уповноважений по милицях в Дарницькі печери 08.11.2014 10:00

Если разработчик один работает над одним проектом, то его польза стремится к нулю.

Вы, видимо, никогда ещё не сидели над собственным кодом годовой давности с вопросом «а какой $удак это написал и почему?» Или же Вы гений (я не из лести, просто судя по тому же поисковику, есть действительно высочайший уровень в некоторых направлениях) — но гению очень часто сложно понять «простых» коллег и их сложности. «Узок их круг, страшно далеки они от народа» ©.

Я для себя ещё с первых доступных SCM средств (RCS, CVS) нашёл, что даже для персональной разработки они очень полезны. При длительной истории сложно вспомнить, какой фактор и почему способствовал конкретному изменению и особенно результату — можно считать, что это вариант коллективной работы себя текущего с себя прошлым (причём, таких прошлых обычно несколько, каждые полгода, считай, уже заметно другой человек). Это уж не говоря про то, что эти средства существенно помогают операциям типа перетащить правильный фикс из одного бранча/трейна в десяток других (тоже нормально даже при персональной разработке — представьте себе программу, которая стоит у десятка клиентов, но у каждого подхачена по-своему).

И даже если ими не пользоваться напрямую, то робот, который раз в час/день автоматически коммитит все изменения в локальных рабочих каталогах, позволяет оценить «траекторию» развития.

Ещё крайне полезно не лениться и тратить на каждый коммит всего несколько минут на подробное объяснение, что в нём делается и особенно почему (отличнейшим примером тут является LKML, можно прямо на курсах разработки заставлять подписаться на него и внимательно читать хотя бы пару десятков писем каждый день). Уже через год видна польза, а через 5 неиспользование такого начинает быть фатальным.

DNA Exp

DNA Exp 09.11.2014 16:21

Давайте взглянем на проблему с другой стороны. Человек завел свой пет проджект, у него нет десятка клиентов. У него просто есть маленькая проблема, он когда приходит на работу хочет работать над тем, что у него было дома. Вот и вся его проблема. Именно так топикстартер описывает проблему. И вы ему советуете, установи джит, устани дропбокс, настрой. Сколько он потратит на это времени ? Не глупо будет если в приложении чуть сложнее хелоуворда, которое через неделю возможно вообще будет заброшено, с одним разработчиком, человек будет тратить время на все эти шорохи, на ведение документации, истории изменений ? Если нужно зафиксировать версию ничего не мешает скопировать папочку в архив, написать дату. Если чтото не получилось, у тебя есть версия куда ты можешь откатиться. Это в разы проще чем тратить время постоянно на чекины и синхронизацию. И только когда в проете два и более человек, причем которые чекинят в одно и тоже место, есть очень серьезная потребность в контроле версий.

Valentin Nechayev уповноважений по милицях в Дарницькі печери 09.11.2014 16:36

И вы ему советуете, установи джит, устани дропбокс, настрой. Сколько он потратит на это времени ?

Про дропбокс я ничего не говорил, достаточно банального локального git. (Ну, а бэкапы нужны везде и всегда.) А установить git это даже на Windows сейчас не особо сложно, а на любом Unix (включая Apple системы) вообще делается вполпинка.
(Заодно хочу заметить, что произносится «гит», а не «джит», даже на английском. Хотя это минимальная из поднятых проблем.)

Я вот сегодня на винде codelite поставил, тот в себе подтянул сразу clang, mingw (4.8.1), git клиента и ещё несколько вкусностей — сам, из коробки.

Не глупо будет если в приложении чуть сложнее хелоуворда, которое через неделю возможно вообще будет заброшено, с одним разработчиком, человек будет тратить время на все эти шорохи, на ведение документации, истории изменений ?

Простите, какая такая документация и особенная история? «git commit -a -m current» на каждый поход на перекур в юниксовом шелле или виндовом IDE не просто, а безнадёжно просто.

Если нужно зафиксировать версию ничего не мешает скопировать папочку в архив, написать дату.

А это уже сложнее того, что я описываю.

Это в разы проще чем тратить время постоянно на чекины и синхронизацию.

Для описанного тривиального юзкейса нет никаких затрат времени, особенно «на синхронизацию».

DNA Exp

DNA Exp 09.11.2014 16:53

Про дропбокс я ничего не говорил, достаточно банального локального git.

Он далеко не банален. Эта тулза написана индускими самурями и имеет кучу нитривиальной и костыльной логики. Там даже есть целый пласт команд, типо починить резульаты работы других неудачных команд.

Я вот сегодня на винде codelite поставил, тот в себе подтянул сразу clang, mingw (4.8.1), git клиента и ещё несколько вкусностей — сам, из коробки.

А с ними и новых багов натянул.

Простите, какая такая документация и особенная история? «git commit -a -m current» на каждый поход на перекур в юниксовом шелле или виндовом IDE не просто, а безнадёжно просто.

Зашел на stackoverflow, забил слово git.
47,824 вопросов. Люди спрашивают поди от безнадежной простоты git.
Причем заметьте, я не против контроля версий, это стандарт. Но стандарт в многопользовательских проектах. Не глупо будет потом постить очередной вопрос на stackoverflow, вместо того чтобы работать над сутью проекта ?

Для описанного тривиального юзкейса нет никаких затрат времени, особенно «на синхронизацию».

Ну как нет если есть.
Get last version. И по сети потянул последнюю версию которая была у тебя дома.

Valentin Nechayev уповноважений по милицях в Дарницькі печери 09.11.2014 17:44

Он далеко не банален. Эта тулза написана индускими самурями и имеет кучу нитривиальной и костыльной логики. Там даже есть целый пласт команд, типо починить резульаты работы других неудачных команд.

git хорош тем, что если это всё не использовать, а ограничиться простейшими add/commit/log, можно никогда в эту сложность не лезть, и всё равно получать от него необходимую функциональность.

Зашел на stackoverflow, забил слово git.
47,824 вопросов. Люди спрашивают поди от безнадежной простоты git.

См. выше.

Не глупо будет потом постить очередной вопрос на stackoverflow, вместо того чтобы работать над сутью проекта ?

Глупо. Потому что постить вопрос будет не за чем — всё будет работать безо всяких вопросов. Хотя если кто захочет при наличии свободного времени и настроения попробовать что-то новое за пределами основных потребностей, почему бы и нет?

Ну как нет если есть.
Get last version. И по сети потянул последнюю версию которая была у тебя дома.

Так что не так в данном случае? Возможность потянуть не просто каталог с исходниками, а такой же каталог, где ещё и история, не даёт никакого усложения, но даёт историю.

DNA Exp

Gennady Dogaev full-stack web developer (freelance) 08.11.2014 14:20

Remote Desktop может быть весьма полезен (хотя на любителя, я лично не люблю держать комп включенным без присмотра), но насчёт Git только для команды — Вы неправы. Какие преимущества он даёт:
1) Ветки. Бывает такое, что сел делать задачу, на которую отведена неделя или больше, и вдруг нужно срочно переключиться на другую (баг пофиксить например). Делать это без системы контроля версий — повеситься можно.
2) Иногда забываешь когда написал «вот эту строчку» и зачем. В этом случае также помогает Git.

DNA Exp

DNA Exp 09.11.2014 16:08

Мне проект в котором работает 1 (один) человек и при этом подключены разные Git, Dropbox и прочье напоминает фирму, где работает один плиточник но при этом существует отдел по оптимизации продаж, менеджер по связям, директор, три секретарши и два бухгалтера. ЗАЧЕМ топикстартеру тратить время на эту бюрократию в проекте, если он один работает над этим проектом ? Неужели не проще просто поставить галочку, разрешить уделанный доступ к компьютеру, поставить надежный пароль и забыть за весь этот гемор с синхронизациями и прочьей потерей времени. Ведение документации ради ведения документации. Для чего тратить 20% своего времени на какието бесполезные монкей чекины и раз за разом стягивание версий с сторонних серверов для синхронизации ?

Gennady Dogaev full-stack web developer (freelance) 09.11.2014 16:17

1) Ветки. Бывает такое, что сел делать задачу, на которую отведена неделя или больше, и вдруг нужно срочно переключиться на другую (баг пофиксить например). Делать это без системы контроля версий — повеситься можно.
2) Иногда забываешь когда написал «вот эту строчку» и зачем. В этом случае также помогает Git.

DNA Exp

DNA Exp 09.11.2014 16:24

1. Копируешь папку со своим проектом, ставишь дату релиза. Когда клиент приходит с багом, просто открываешь релиз из этого проекта (один клик), фиксишь баг, отправляешь.
2. Для этого существуют комментарии в коде. Какая разница где их оставлять, в Git или в коде ? В коде удобней, как по мне.

Gennady Dogaev full-stack web developer (freelance) 09.11.2014 16:30

Копируешь папку со своим проектом, ставишь дату релиза. Когда клиент приходит с багом, просто открываешь релиз из этого проекта (один клик), фиксишь баг, отправляешь.

Ага, а потом долго руками склеиваешь багфикс с новым кодом. И имеешь на диске десяток полных копий проекта.

Для этого существуют комментарии в коде. Какая разница где их оставлять, в Git или в коде ? В коде удобней, как по мне.

На каждую строку по комментарию с описанием задачи или один комментарий с описанием задачи (или вообще ссылкой на трекер) в Git?

DNA Exp

DNA Exp 09.11.2014 16:42

Ага, а потом долго руками склеиваешь багфикс с новым кодом. И имеешь на диске десяток полных копий проекта.

Зачем склеивать ? Я как понял интересовало как без Git разруливается проблема с бранчами. Когда более старую версию установил клиент, работа пошла над новой версие, но клиенту не нужно ждать новую версию а нужно срочно чтото исправить в той старой.

На каждую строку по комментарию с описанием задачи или один комментарий с описанием задачи (или вообще ссылкой на трекер) в Git?

Для чего на каждую строчку ? Там где это требуется.
Я вообще не встречал, где комитят каждую строчку кода с очень подробными коментариями даже на рабочих многопользовательских проектах.

Gennady Dogaev full-stack web developer (freelance) 09.11.2014 16:46

более старую версию установил клиент, работа пошла над новой версие, но клиенту не нужно ждать новую версию а нужно срочно чтото исправить в той старой.

А в новой баг пусть остаётся? Если он в старой есть — он и в новой есть. Как в новую переносить фикс? Руками не особо продуктивно.

Для чего на каждую строчку ? Там где это требуется.

Так вот прямо сейчас пишешь — всё понятно (такого чтобы было непонятно написанное минуту назад я не встречал). Через полгода — не помнишь зачем это тут и что оно делает.

DNA Exp

DNA Exp 09.11.2014 16:56

А в новой баг пусть остаётся? Если он в старой есть — он и в новой есть. Как в новую переносить фикс? Руками не особо продуктивно.

Каждый случай индивидуален. В новой версии вообще может быть все по новому или переписано. Наивно думать что за тебя контроль версий может пофиксить в «автоматическом режиме»

Valentin Nechayev уповноважений по милицях в Дарницькі печери 09.11.2014 17:47

Наивно думать что за тебя контроль версий может пофиксить в «автоматическом режиме»

Но в >90% случаев это так. И автоперенос патча решает эту проблему.

DNA Exp

Dmytro Sirenko SRE 08.11.2014 17:01

git, svn, mercury, vss и прочьи приблуды в основном нужны, когда над проектом работает команда разработчиков.

— я вважаю, що git, svn, hg та інші приблуди не потрібні в основному тоді, коли вашим продуктом користується тільки одна людина.

DNA Exp

Tim Tretyak ASM, TS Consultant в Hewlett Packard Enterprise 09.11.2014 19:27

RDP в принципе нормальная идея, но не лишен некоторых недостатков.
1. Виндовс крайне желательно поставить на автоапдейт, иначе рано или поздно произойдет ой.
2. Некоторые вещи неприятно тупят, типа скроллинга.
3. Различные приблуды, требующие хардварного ускорения графики, работают обычно хреново.
.
Ну последнее — если работать по найму, то секьюрити работодателя эта идея чаще всего категорически не нравится. Хотя как где.

DNA Exp

Maksim Babenko Java Dev в Успешная динамично развивающаяся компания мечты 07.11.2014 15:38

ну раз пошел такой разговор, то чем teamviewer плох? :)

DNA Exp

Yury Gavrilenko 07.11.2014 00:10

google: git, mercurial; github, bitbucket, gitlab;
І постав android studio замість екліпса.

Valentin Yuryev нажимаю кнопочки 07.11.2014 00:06

Github.com

Eclipse лучше заменить на Andoid Studio — там есть встроенная поддержка различных VCS, что упростит процесс синхронизации кода.

Олександр Зайцев Android Engineer 07.11.2014 17:13

в эклипсе есть eGit :)

Valentin Yuryev

Michael P Software Developer в Xenoss 06.11.2014 18:25

Bitbucket с бесплатными приватными репами или гитлаб с тем-же. Довольно удобные сервисы для этого, и в самом эклипсе поддерживаются )))

Oleksandr Bardanov Senior Software Developer 06.11.2014 17:18

Если не устраивает православный GitHub, то можно сохранять проект в папку дропбокса.

Nickolay Kondratenko Developer в Svitla 07.11.2014 13:48

как самый очевидный плюс — не надо дополнительных телодвижений
как самый очевидный минус — синхронизация занимает определённое время, что может поломать данные

Пробовал дропбокс для синхронизации кода, который рука не поднималась закоммитить.

Также можно разместить на дропбоксе репозиторий. Минус остаётся — в локальную папку мы-то запушим быстро, а синхронизация занимает время. Для количества разработчиков > 1 однозначно не пойдёт. Плюсов явных не вижу. Приватный репозиторий можно и на битбакете получить

Oleksandr Bardanov

Hnat Kubov 07.11.2014 20:03

А можна git init --bare в папці на дропбоксі, потім git clone ~/Dropbox/myproject.git ~/code/myproject і поєднати таким чином одне з іншим. Сто раз так робив для проектів, де я був єдиний розробник. І код не пропаде, якщо жорсткий диск зламається, і історія комітів є, і синхронізуватись з різних машин можна. Теоретично можна і в команді так працювати, але це вже трохи збочення.

Oleksandr Bardanov

anonymous 08.11.2014 14:49

Ну bitbucket же

Hnat Kubov

Hnat Kubov 08.11.2014 18:05

Bitbucket звісно «же», але якщо питання командної розробки взагалі не стоїть, то чом би й не дропбокс.

anonymous

anonymous 09.11.2014 00:19

А чом би не мати історію та зручний бранчінг?

Hnat Kubov

Hnat Kubov 09.11.2014 00:42

Так ніхто ж не боронить! Я писав про локальний remote (ха-ха, оксюморон) в папці на Dropbox. Штовхаєш в локальний каталог, а Dropbox займається синхронізацією. Коли працюєш сам, то в такій схемі відмінностей із bitbucket не так і багато. Якби хоча б у bitbucket був пошук по коду, як на github, то був би якийсь плюс. Але Atlassian не надто квапляться закривати цей feature request.

en.wikipedia.org/...evision_control

anonymous

Mikhail Boiko SE в NVIDIA 06.11.2014 17:17