Работа на двух пк над одним проектом

@mastercard · Регистрация: 22.12.2016

Author24 — интернет-сервис помощи студентам

В общем, имеется проект который частенько нужно обновлять, и не всегда удаётся побыть 1на1 с проектом на пк, иногда нужно уезжать по делам имея с собой ноутбук и интернет, собственно вопрос: Возможно ли поместить проект в облако, что бы в случае если у меня нет доступа к пк , я спокойно мог продолжить писать код уже с ноутбука, есть конечно флешка, но это как то муторно что ль, каждый раз перед уходом закачивать всё с пк на флешку, а затем вставлять в ноут(хотя можно делать проект на флешке, но как то не безопасно, вдруг флешка в один прекрасный момент - всё.)

@aquaMakc · 15.08.2017, 11:29

Лично я пользуюсь связкой TortoiseHg + yandex.disk для синхронизации своих проектов + контроль версий.

@Rius · 15.08.2017, 11:41

Сообщение от Usaga

Хотя битбакет никто не отменял

Вот именно, BitBucket

И Gitlab ещё.

Сообщение от Usaga

Зря вы так негативно.

Это же MS, иначе никак. За ними куча фейлов, NIH и разрушений. Начиная от конкуренции в табличных редакторах и браузерах (где сначала сделали своё, совместимое, а когда народ подсел - несовместимое и vendor lock), и заканчивая разрушением Нокии и провалом на рынке смартфонов.

Добавлено через 7 минут
aquaMakc, те же самые недостатки облачного диска, слегка нивелированные применением DVCS. Учитывая поддержку Mercurial в Bitbucket, преимуществ по сравнению с ним нет, одни недостатки.

@aquaMakc · 15.08.2017, 11:47

Rius, Для меня основной плюс - удобство и простота использования. я.диск у меня итак подключен на всех моих ПК, т.к. с некоторых пор на нём 120 гигабайт и там много чего храню. Git пробовал. Не увидел существенных преимуществ перед уже имеющейся схемой. Разве-что, возможность фиксации изменений прямо из IDE (при этом допускаю, что есть возможность такой-же работы с Tortoise из VS, просто руки не доходят проверить).
На я.диске хранилище, в которое протакливаю/ из которого вытягиваю изменения в локальные репозитории. Да, могу работать с хранилищем только я, но меня это вообще не напрягает, т.к. больше никто над моими проектами не работает.
Потребуется командная работа - буду смотреть на публичные хранилища.

@Rius · 15.08.2017, 12:01

Сообщение от aquaMakc

Разве-что, возможность фиксации изменений прямо из IDE (при этом допускаю, что есть возможность такой-же работы с Tortoise из VS, просто руки не доходят проверить).

Не, это не особое преимущество. Ни одна IDE не умеет работать с VCS так, как родная консольная утилита.

Сообщение от aquaMakc

Git пробовал. Не увидел существенных преимуществ перед уже имеющейся схемой.

Hg и Git похожи. На Git перешёл, потому что в нём тогда можно было удобно коммитить отдельные изменённые строки, а не только целыми файлами.

Сообщение от aquaMakc

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

Это недостаток, с которым вы смирились, ок. Помимо этого есть и другие:

Синхронизация работает по своим алгоритмам, которыми вы особо не управляете;
Вы, конечно, можете попросить клиент Я.Диска произвести синхронизацию именно сейчас, и он если соизволит - выполнит. А может затупить и всё, а вам уже бежать надо;
Файлы репозитория копируются локально на ПК, синхронизацией. И могут быть повреждены как любой файл на диске. С DVCS проблему можно устранить, если перезалить данные заново в этот локальный репозиторий. Но при неудачном стечении обстоятельств можно словить большой фейл, когда файлы вот они, синхронизированные, но клиент VCS на этот репозиторий ругается, и обновлённые файлы из него не вытащить.

@aquaMakc · 15.08.2017, 12:48

Сообщение от Rius

Помимо этого есть и другие:

баги синхронизации и файловой системы могут воспроизвестись в любой момент и не зависят от инструмента синхронизации.

Добавлено через 15 секунд

Сообщение от Rius

Помимо этого есть и другие:

баги синхронизации и файловой системы могут воспроизвестись в любой момент и не зависят от инструмента синхронизации.

@Rius · 15.08.2017, 13:08

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

@aquaMakc 484 / 397 / 68 Регистрация: 14.02.2014 Сообщений: 1,930
	15.08.2017, 11:29	21
	Лично я пользуюсь связкой TortoiseHg + yandex.disk для синхронизации своих проектов + контроль версий. 0

@aquaMakc 484 / 397 / 68 Регистрация: 14.02.2014 Сообщений: 1,930
	15.08.2017, 11:47	23
	Rius, Для меня основной плюс - удобство и простота использования. я.диск у меня итак подключен на всех моих ПК, т.к. с некоторых пор на нём 120 гигабайт и там много чего храню. Git пробовал. Не увидел существенных преимуществ перед уже имеющейся схемой. Разве-что, возможность фиксации изменений прямо из IDE (при этом допускаю, что есть возможность такой-же работы с Tortoise из VS, просто руки не доходят проверить). На я.диске хранилище, в которое протакливаю/ из которого вытягиваю изменения в локальные репозитории. Да, могу работать с хранилищем только я, но меня это вообще не напрягает, т.к. больше никто над моими проектами не работает. Потребуется командная работа - буду смотреть на публичные хранилища. 0

@aquaMakc 484 / 397 / 68 Регистрация: 14.02.2014 Сообщений: 1,930
	15.08.2017, 12:48	25
	Сообщение от Rius Помимо этого есть и другие: баги синхронизации и файловой системы могут воспроизвестись в любой момент и не зависят от инструмента синхронизации. Добавлено через 15 секунд Сообщение от Rius Помимо этого есть и другие: баги синхронизации и файловой системы могут воспроизвестись в любой момент и не зависят от инструмента синхронизации. 0

@Rius 10542 / 6470 / 1502 Регистрация: 25.05.2015 Сообщений: 19,606 Записей в блоге: 14
	15.08.2017, 13:08	26
	Верно. Поэтому для резервных копий по хорошему используется не синхронизация, а версионирование. Потому что синхронизация, будучи проведённой с ошибками, или поверх повреждённых данных, распространит повреждения и по всем остальным копиям. А общение с сервером хранения репозиториев по его протоколу обмена эту проблему исключает. 1

@mastercard 1 / 3 / 2 Регистрация: 22.12.2016 Сообщений: 144
		1
	Работа на двух пк над одним проектом 14.08.2017, 23:23. Показов 11814. Ответов 25 Метки нет (Все метки) В общем, имеется проект который частенько нужно обновлять, и не всегда удаётся побыть 1на1 с проектом на пк, иногда нужно уезжать по делам имея с собой ноутбук и интернет, собственно вопрос: Возможно ли поместить проект в облако, что бы в случае если у меня нет доступа к пк , я спокойно мог продолжить писать код уже с ноутбука, есть конечно флешка, но это как то муторно что ль, каждый раз перед уходом закачивать всё с пк на флешку, а затем вставлять в ноут(хотя можно делать проект на флешке, но как то не безопасно, вдруг флешка в один прекрасный момент - всё.) 0

@Rius 10542 / 6470 / 1502 Регистрация: 25.05.2015 Сообщений: 19,606 Записей в блоге: 14
	15.08.2017, 11:41	22
	Сообщение от Usaga Хотя битбакет никто не отменял Вот именно, BitBucket И Gitlab ещё. Сообщение от Usaga Зря вы так негативно. Это же MS, иначе никак. За ними куча фейлов, NIH и разрушений. Начиная от конкуренции в табличных редакторах и браузерах (где сначала сделали своё, совместимое, а когда народ подсел - несовместимое и vendor lock), и заканчивая разрушением Нокии и провалом на рынке смартфонов. Добавлено через 7 минут aquaMakc, те же самые недостатки облачного диска, слегка нивелированные применением DVCS. Учитывая поддержку Mercurial в Bitbucket, преимуществ по сравнению с ним нет, одни недостатки. 1

@Rius 10542 / 6470 / 1502 Регистрация: 25.05.2015 Сообщений: 19,606 Записей в блоге: 14
	15.08.2017, 12:01	24
	Сообщение от aquaMakc Разве-что, возможность фиксации изменений прямо из IDE (при этом допускаю, что есть возможность такой-же работы с Tortoise из VS, просто руки не доходят проверить). Не, это не особое преимущество. Ни одна IDE не умеет работать с VCS так, как родная консольная утилита. Сообщение от aquaMakc Git пробовал. Не увидел существенных преимуществ перед уже имеющейся схемой. Hg и Git похожи. На Git перешёл, потому что в нём тогда можно было удобно коммитить отдельные изменённые строки, а не только целыми файлами. Сообщение от aquaMakc На я.диске хранилище, в которое протакливаю/ из которого вытягиваю изменения в локальные репозитории. Да, могу работать с хранилищем только я, но меня это вообще не напрягает, т.к. больше никто над моими проектами не работает. Это недостаток, с которым вы смирились, ок. Помимо этого есть и другие: Синхронизация работает по своим алгоритмам, которыми вы особо не управляете; Вы, конечно, можете попросить клиент Я.Диска произвести синхронизацию именно сейчас, и он если соизволит - выполнит. А может затупить и всё, а вам уже бежать надо; Файлы репозитория копируются локально на ПК, синхронизацией. И могут быть повреждены как любой файл на диске. С DVCS проблему можно устранить, если перезалить данные заново в этот локальный репозиторий. Но при неудачном стечении обстоятельств можно словить большой фейл, когда файлы вот они, синхронизированные, но клиент VCS на этот репозиторий ругается, и обновлённые файлы из него не вытащить. 0