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

Такой вопросец! Веду разработку приложения(Андроид) в эклипсе на домашнем пк. Задумываюсь взять ещё ноут, чтобы кодить вне домаю. Каким образом можно было бы синхронизировать проект, чтобы я мог работать над одним и тем же кодом и домашнем пк и на ноуте и код бы автоматом обновлялся и там и там? Быть может есть удобные сервисы для этого или в самом эклипсе есть что-то подобное?

До обраного В обраному 0

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

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

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

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

GitHub или Assembla

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

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

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

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

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

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

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

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

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

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

Этот комментарий удален правообладателем.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

rsync или ssh agent forwarding

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Static IP + Remote desktop

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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