Контроль версій на основі портативного сховища?

9

Я розробляю особисті проекти на двох машинах без використання спільного сервера або мережевого з'єднання між ними.

Чи якісь загальноприйняті системи управління версіями надійно підтримують використання портативного сховища (наприклад, флеш-пам'яті USB) як спільного сховища?

version-control

— billpg
джерело

Чому ви хочете / потрібно використовувати портативний накопичувач?

— Бернард

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

— billpg

Я мав звичай використовувати набір ртутних сховищ на флеш - накопичувачі USB для оновлення виробництва інструментів на заводі , і вона працювала дуже добре. Ви навіть могли бачити, коли технічні працівники на місці змінювали код на локальній машині, поки ви не були, і об'єднуєте їх (або відхиляєте) їх зміни, перш ніж синхронізувати їх зміни на флешку.

— Марк Бут

Тут уже сказано, що SVN підтримує локальне зберігання, і ви можете використовувати usb. Але я вважаю за краще зберігати його БД у моїй приватній папці DropBox;) Ви також можете користуватися багатьма безкоштовними сервісами (наприклад, assembla або tfs.visualstudio.com)

— Павло Воронін

31

Використовуйте DVCS, такі як Git або Mercurial .

Системи управління розподіленими версіями не мають спільного центрального сервера.

За допомогою DVCS кожна копія сховища містить повну історію - все. Це означає, що при використанні на USB-клавіші будь-які зміни, які ви вносите, вносяться до сховища на USB-ключі, а при переміщенні між комп’ютерами буде зберігатися ця історія.

— Одіє
джерело

9

І якщо ви використовували github, вам навіть не доведеться носити USB-накопичувач

— CamelBlues

Дякую. Чи можна налаштувати використання портативного сховища як сховища?

— billpg

@billpg - Так. Він просто живе в структурі каталогів.

— Oded

@CamelBlues або bitbucket або kilnhg або, ймовірно, різні інші, які можуть бути або не підходять ...

— Мерф

3

У мене є основні персональні сховища Mercurial на DropBox. Відмінно працює і автоматично реалізує резервне копіювання (оскільки DropBox навряд чи піде з ладу в той же час, коли я втрачаю всі свої комп’ютери).

— Девід Торнлі

7

Крім GIT, Mercurial тощо, запропоновані вище, також мають огляд Fossil - Він має переваги в тому, що бінарні файли часу запуску невеликі (1Meg або близько для Windows і Linux), потрібна портативна та нульова установка. Тому, на відміну від інших (наскільки мені відомо), його можна поставити на запам'ятовуючий пристрій і запустити на будь-якій машині, до якої зберігається підключення пам’яті, без попереднього встановлення програми на машину. Він включає систему Wiki та систему відстеження змін / дефектів з репо. У ньому також вбудований gui.

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

— mattnz
джерело

Хоча Git приймає команду Unix робити одне і робити це добре серйозно, ви можете мати такі функції в Git через такі розширення, як ticgit (система квитків) та gollum (вікі на основі репо).

— Джейсон Льюїс

@Jason Lewis: Ви маєте рацію, і, оскільки це відкритий код, ви можете просто змінити його, щоб відповідати вашим вимогам, так що GIT (або будь-який інший інструмент) може бути будь-яким для всіх (хто може турбувати, має вільний час та ресурси завантажити, встановити та налагодити всі "плагіни". Все, що я говорив, - це рішення, яке "Просто працює з коробки", варто розглянути Fossil.

— mattnz

1

Використання DCVS - це, мабуть, хороша ідея, але це не єдиний варіант.

У мене невелике сховище CVS на USB-накопичувачі. Коли я хочу отримати доступ до нього, мені просто потрібно скористатися cvs -d <path>або встановити $CVSROOTшлях до кореня сховища (що, звичайно, вимагає встановлення в системі великого пальця).

Якщо ви вже звикли використовувати CVS, це має бути працездатним. Те саме має стосуватися SVN. Це просто означає, що ваше центральне сховище знаходиться на накопичувачі, і воно не завжди видно.

Є аргументи для використання DCVS, а не CVS взагалі. Я не думаю, що на ці аргументи особливо впливає те, чи знаходиться центральне сховище на палець-накопичувачі чи десь ще. Наприклад, ви можете так само легко створити сховище git на великому диску.

— Кіт Томпсон
джерело

1

Я, як правило, не є великим шанувальником DVCS, але я думаю, що DVCS в цьому випадку буде кращим. Проблема з нерозподіленим VCS полягає в тому, що репо є єдиною точкою відмови. Якщо він сидить в центрі обробки даних з контрольованим кліматом і отримує регулярне резервне копіювання, це не має великого значення - але що - то як флеш - накопичувач буде губитися (або наступити на нього , або з'їдений собакою чи опускають в Білий російський) рано чи пізніше.

— Майк Баранчак

1

@MikeBaranczak: Добре - але все, що є на палець, слід регулярно створювати резервні копії, будь то сховище CVS чи ні.

— Кіт Томпсон

при розподіленій системі кожен клієнт вже має повну копію репо. Тому немає ніякої причини для окремої процедури "резервного копіювання".

— Майк Баранчак

1

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

— Кіт Томпсон

0

Як додаток до інших відповідей:

Хоча DVCS дуже добре відповідає цій проблемі, ви технічно можете також використовувати Subversion, якщо вам це зручніше. Subversion може використовувати локальний каталог замість центрального сервера. Ви можете просто поставити це на привід великого пальця і використовувати його.

Недоліком порівняно з DVCS є те, що ви можете працювати лише з Subversion (тобто здійснювати фіксацію, переглядати журнали тощо), коли пристрій підключено до палець. Також, він повинен бути завжди одним і тим же приводом великого пальця (або принаймні вгору -копія дати), тому що з Subversion ви не повинні використовувати більше одного сховища (це нерозподілена частина). Тож якщо ви коли-небудь забудете великий палець, ви не можете його використовувати, на відміну від Git або Mercurial.

Примітка:

Як було пояснено вище, і в коментарях DVCS справді краще підходить для вашої проблеми. Я лише згадав про Subversion заради повноти, і якщо у вас є якісь особливі причини використовувати Subversion.

— sleske
джерело

1

Як і у відповіді Кіта , проблема з VCS в локальному каталозі полягає в тому, що це єдина точка відмови. Крім того, якщо ви переходите з машини A на машину B, але залишаєте привід великого пальця підключеним до машини A, тоді вам набагато менше шансів потурбуватися, якщо ви використовуєте DVCS (ви завжди можете злитися в локальних змінах пізніше), тоді як з VCS , вам доведеться повернутися до машини A, отримати привід і повернутися до машини B, перш ніж ви зможете продовжити.

— Марк Бут

@MarkBooth: Я не виступаю за це рішення, я просто хотів зазначити, що воно існує, задля повноти і на випадок, якщо ОП має якісь особливі переваги щодо Subversion. Я відредагував свою відповідь, щоб зробити це зрозумілим.

— sleske

Дякую @sleske, я погоджуюсь, що перевага svn(або справді Cv) може зважуватись на користь використання цього рішення, але в інтересах повного розкриття слід також згадати і недоліки цього підходу. Не соромтесь редагувати пункти мого коментаря до вашої відповіді. Якщо ви це зробите, я би радий очистити (видалити) свої коментарі. * 8 ')

— Марк Бут

Я не впевнений, що ця відповідь додає, що я вже не сказав у своєму.

— Кіт Томпсон

1

@KeithThompson: Він додає інформацію про те, що SVN може використовувати локальний каталог замість центрального сервера. Це пояснюється в документах SVN, але оскільки більшість людей використовує SVN через центральний сервер, може бути не очевидно, що SVN не вимагає сервера.

— sleske