Використання спільної робочої області git на кількох хостах


0

Я переходжу свої особисті проекти з використання subversion (svn) на GIT. У підривній роботі я використовував спільний робочий каталог SVN на декількох хостах (незважаючи на те, що люди мені казали, що це не буде працювати), і це доводиться, що він добре працює на мене. Важливо зазначити, що це єдине користувацьке рішення, і я єдина людина, яка вносить зміни, тому я не запускаю SVN-зобов’язання в декількох полях одночасно. Коротше кажучи, я готовий жити з деякими обмеженнями (якщо потрібно), щоб спростити загальне управління своїми особистими проектами.

Щоб зрозуміти, чому я хочу це зробити, розгляньте мою конфігурацію (нижче). У мене є кілька приємних машин, на яких працює декілька візків. У мене є кілька великих дисків на "host1" і є спільні файли, до яких доступ до інших хостів (у локальній локальній мережі).

host1 (share \\host1\share)
  +vm1 (access SVN working dir \\host1\share\svnproj1, and svnproj2)
  +vm2 (access SVN working dir \\host1\share\svnproj1)
  +vm3 (access SVN working dir \\host1\share\svnproj1)

host2
  +vm4 (access SVN working dir \\host1\share\svnproj1)
  +vm5 (access SVN working dir \\host1\share\svnproj1)

laptop (access SVN working dir \\host1\share\svnproj1)
     But also have a svn checkout at c:\svnproj1

Усі ОС - це Win7x64 або Win8.1x64. Наразі я використовую Tortoise SVN 1.8.2 та subversion 1.8.3 (для ВСІХ хостів).

Цей підхід дозволяє мені отримувати доступ до спільного доступу до файлу сервера (\ host1 \ share) з будь-якого хоста. У деяких випадках моїм репортажам svn є багато років і старше 2 GIG, які мають окремі "SVN робочі зони" в кожному VM, збільшують мої відеомагнітофони більше і ускладнюють мої знімки та резервні копії VM.

Мені також не потрібно вводити файли, поки я не візьму ноутбук на ділову зустріч. Я працюю вдома, тому це не часто. Коли я повертаюся з ділової зустрічі чи поїздки, я здійснюю свої зміни на своєму ноутбуці та оновлюю запуск оновлення svn на будь-якому з 5-ти VM, а файли оновлюються на всі 5 ВМ. Для мене це досить просто і добре працює.

Тож зараз мені цікаво, чи може цей самий підхід працювати за допомогою GIT. Все, що я прочитав, говорить, що ви не можете (або не повинні цього робити).

Ось питання, які у мене є, допоможуть мені зрозуміти, чи це навіть технічно можливо (ПРИМІТКА. Я вже експериментую з таким підходом).

  1. (Q) Чи зберігає GIT інформацію про хост поза репортажем GIT (.git dir) та чи потрібна ця інформація для правильного управління gpo repo. Якщо це так, то мати декілька машин, налаштованих однаково з цією інформацією, неможливо.

  2. (Q) Чи створює GIT тимчасові файли в робочій області GIT? Якщо це так, чи буде ця інформація про темп викручувати ще одну копію git, що працює на іншій машині? Якщо так, то знову ж таки такий підхід недоцільний.

  3. (Q) Чи GIT має таку саму проблему, що і Subersion, оскільки всі клієнти, які використовують даний репо, повинні мати однакову версію?

  4. (Q) Чи не вдасться цей підхід, якщо введено іншу ОС (Linux, Apple OSX)?

  5. (Q) Якщо використовується такий постачальник хмарних сховищ, як Dropbox або SpiderOak, це рішення все ще працює?

  6. (Q) Чи є інші питання або проблеми, з якими я можу зіткнутися під час використання GIT, які я б не побачив при використанні SVN.

Знову ж таки, важливо відзначити, що для цього рішення потрібно працювати лише для мене, ніколи не буде багато людей, які вносять зміни до сховища GIT, і я можу жити з деякими обмеженнями, якщо це спростить загальне управління VM.

Ця стаття http://www.sitepoint.com/how-to-use-dropbox-with-svn-or-git-for-cloud-source-control-management/ зробила чудову роботу, пояснивши, як використовувати GIT в традиційний спосіб. Для мене рішення Dropbox еквівалентно локальній частці файлів локальної мережі.

Відповіді:


1

Це повинно працювати без проблем. Просто поставте своє git repo там, де поточний робочий каталог svn знаходиться на хості1. Я зробив щось подібне, коли я поділяю git repo між декількома комп'ютерами, що використовують Dropbox (що насправді менш доцільно, ніж те, про що ви говорите, тому що Dropbox створить окрему версію репо, якщо вона не може синхронізуватися).

Ось відповіді на поставлені вами питання.

  1. У .gitconfigпапці у вашому домашньому каталозі є деяка інформація , але все це витісняється будь-якою інформацією конфігурації в .gitпапці, яка є повністю портативною. Це не повинно викликати жодних проблем. Одне - будьте обережні, щоб вибрати однаковий варіант для закінчень рядків у всіх системах або налаштувати його в .gitпапці.
  2. Ні (принаймні, не те, що мені відомо). Всі версії зберігаються у папці .git, а робоча копія - це лише звичайні файли.
  3. Найкраще було б, якщо вони працюють з однією і тією ж версією git, щоб у вас не виникли дивні помилки, але це може не спричинити проблем, якщо вони будуть різними версіями, а ви виконували лише основні завдання.
  4. ОС не зміниться, оскільки .gitпапка буде однаковою. Просто виберіть відповідний варіант для закінчень рядків і виберіть однаковий варіант для всіх систем.
  5. Так, я це зробив на Dropbox. Єдина проблема полягає в тому, що якщо Dropbox не синхронізується та створить конфліктну копію вашого сховища. Тоді у вас болить голова, щоб зрозуміти, який з них є вашими останніми вчинками. Це не працює для одночасного доступу кількох користувачів, оскільки кожному користувачеві потрібна своя робоча копія.
  6. Ніяких великих. Я переключився на свої особисті проекти деякий час тому, і це було досить гладко. Є інструменти, які допоможуть вам імпортувати свою svn історію до git, якщо хочете.
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.