Альтернативи професійному контролю версій [закрито]

Ми об'єднуємось з деякими непрограмістами (сценаристами), яким потрібно внести свій внесок у один із наших проектів.

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

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

Я придумав кілька ідей ...

• скажіть їм, щоб вони зберігали свою роботу як окремий файл щоразу, коли вони вносять якісь нетривіальні зміни, а потім використовуйте diff з нашої сторони, щоб просто відстежувати зміни.
• написати програму (на Python), яка певним чином реалізує "основні етапи" в CSSEdit.

Про проект:

Це природна система обробки мови (написана на C + Python). Ми найняли деяких авторів, які готували матеріали для різних мов. І коли ми розвиваємо програмне забезпечення, нам потрібні будуть ті автори, щоб внести зміни у свої матеріали (статті). Іноді зміни дуже малі (слово-два), а в інший час великі.

Причина, що нам потрібно контролювати версії цих змін, полягає в тому, що кожна невелика / велика зміна входу може потенційно змінити вихід системи.

коли я вперше познайомив їх із розгалуженням та злиттям - вони виглядали так, що я їх ображаю

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

То чому б не пояснити просто "фіксація" (збереження) та "оновлення"? Дві дійсно прості концепції. Я впевнений, що ви можете пояснити це менш ніж за 10 хвилин.

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

Досить неортодоксальним підходом було б просто використання Dropbox . Запропонуйте авторам зберегти файли в папці, що випадає, і ви отримаєте версію та резервну копію безкоштовно. Плюс до того, що для авторів крива навчання в основному відсутня.

Що стосується git, це виглядає так, як врешті-решт, ви все-таки надасте авторам правильні версії гілок, так що просто покладіть git repo в падіння і обробіть розгалуження та злиття для авторів.

Відповідь правдиво є у вашій редакції: "Ми найняли деяких письменників" - іноді вам просто до душі ... вони хочуть, щоб ваші гроші мали робити те, що ви хочете, якщо те, що ви хочете, не є нерозумним.

Аргумент, який ви висуваєте, - це аргумент, який ви вже висунули - нам потрібно вміти робити X, Y і Z, щоб продукт працював - і для цього нам потрібно, щоб ви це зробили. Ми будемо настільки прихильними, як можемо, але для того, щоб це працювало (а отже, щоб воно продовжувалося як потік доходів для вас, письменника), це має відбутися.

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

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

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

Третя сторона надсилає мені щоденно поштовий файл своїх файлів проектів, і я б робила для них реєстрацію. Я встановив для них окремий робочий простір проекту та svn-акаунт, і розпакував би файли в цю робочу область, перезаписавши те, що там було, а потім зробити реєстрацію під цим обліковим записом.

Це не найсмішніше робити щодня, але іноді важливіше просто виконати роботу.

Одним із плюсів було те, що він допоміг мені переглянути їхню роботу, щоб переконатися, що вони не перевіряли неправильний код та дані, які порушили збірку.

SparkleShare - це клонінг -клон на основі git, я думаю, він відповідає вашим потребам.

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

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

Чудово

• Часто змінюються файли проектів, як-от текст, офісні документи та зображення
• Відстеження та синхронізація файлів, відредагованих кількома людьми
• Повернення файлу до будь-якої точки його історії
• Запобігання шпигуванню ваших файлів на сервері за допомогою шифрування

Не такий великий

• Повне резервне копіювання комп'ютера
• Зберігання вашої фотографії чи музичної колекції
• Великі бінарні файли, які часто змінюються, як проекти редагування відео ...

Оновлення (листопад 2015 р.) : Проект, здається, покинутий (останній реліз з квітня 2014 року).

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

Просто знайдіть редактор із вбудованою підтримкою VCS, налаштуйте його та покажіть додаткові прості кроки у своїх роботах.

Приклад - Editplus знає про Subversion, має можливість виконувати основні SVN-операції у вікні редактора. Останній Editplus навіть може використовувати TortoiseGIT для Git-інтеграції

Редагувати : знайдено альтернативне рішення: EasySVN , який, будучи належним чином налаштований, контролює робочу копію та виконує автокомісію та автоматичну автоматизацію, дозволяючи використовувати будь-який інструмент створення для кінцевого користувача та будь-які формати документа

Що з налаштуванням WebDAV ?

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

Документи Google

Документи Google можуть робити все, що ви хочете. File > See Revision Historyдозволить вам стежити за змінами.

Ви також отримали проблему з безкоштовною передачею файлів назад і назад; просто поділіться документом між усіма.

Нарешті, це просто у використанні; письменники навіть не повинні знати, що відбувається версія.

OS Agnostic

Напишіть програму на мові Python , який ви можете перетягнути файл на, що програма може зробити git addі , git commitа що ні , і вони ніколи не повинні мати справу з ним.

або

Використовуйте файлову систему на базі WebDav, яку ви зможете встановити на їх машину, і сервер робити це gitпрозоро.

OSX / Linux

Напишіть плагін FUSE на основі Python, який приймає файли та зобов’язує їх git. Тоді вони можуть просто відкриватися та зберігатись із змонтованої файлової системи. Є деякі ПОПЕРЕДЖЕННЯ для ресурсів Windows , але їх, мабуть, навіть не варто дурити.

Windows

Ви можете написати код, щоб використовувати драйвери фільтрів FileSystem для прозорого виконання цього завдання git.

Ах, радості некодерів, що глузують. Я б запропонував створити для них середовище git / mercurial. Скажіть їм зберегти все у форматі, з яким може працювати репо. З черепахом або черепахою їм не потрібно знати, як працює репо. Вони просто перевіряють, чи є в їхньому каталозі проектів знак оклику, клацніть правою кнопкою миші файл, який порушує праворуч, і натисніть кнопку "Здійснити". Введіть конспект змін (вони письменники, правда?), І все закінчено!

Додатковий крок у робочому процесі для них, але нічого про злиття / розгалуження / класні речі. Заздалегідь створене середовище вже створене для того, щоб бути у відділенні авторів, тому вони не бачать код. Попросіть сценарій автоматично синхронізувати їх щодня. Пізніше, коли вони звикли до вчинення, ви можете показати їм додаткові функції. Можливість бачити, що змінилося, коли настільки корисно, що вони не зможуть обійтися без цього, як тільки ви прокрадете їх у їх робочий процес.

А як щодо Share Point? Я знаю, що це не популярно у світових розробках, але якщо ваші автори використовують Windows як ОС, вона буде працювати добре, і вони не дійсно будуть знати, що вони використовують контроль над версіями (великий плюс для моєї роботи).

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

Чи можете ви налаштувати інструмент, який слідкує за файловою системою, куди письменники зберігають свої файли, і чи дозволяють вони робити автоматичне виконання кожного разу, коли вони роблять збереження?

Якщо ви розмістите його на мережевій папці, ви могли б виконати всю конфігурацію, не залучаючи їх взагалі; але кожен раз, коли вони надавали оновлену версію для вашої команди, щоб використовувати її, вона буде додаватися до git для вас.

Ви подивилися на Plastic SCM. Вони намагаються зробити його простішим у використанні

Якщо ви просто хочете розробити резервні копії, ви можете використовувати Dropbox або налаштувати службу резервного копіювання Windows. Або ви можете встановити Crashplan або інший подібний продукт.

Для Mercurial DVCS існує інтерфейс користувача під назвою EasyMercurial , метою якого є явне надання простого перегляду основних операцій управління версіями.

EasyMercurial призначений для:

• простий у навчанні та вивченні вказівки на фактичний стан сховища, використовуючи графічне подання історії
  • впізнавано близький до нормального робочого процесу командного рядка для Mercurial, послідовного на всіх платформах

Ми не намагаємось виготовити "найкращого" клієнта Mercurial з будь-якою метою. Ми активно заохочуємо користувачів переходити до інших клієнтів у міру розвитку їх потреб. Мета - просто забезпечити щось доступне для початківців у невеликих проектних групах, що працюють із спільним віддаленим сховищем.

Я рекомендую спробувати.

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

1. Прикиньте себе програмістами, спробуйте навчити їх користуватися керуванням версіями. Це не вийде, і у вас будуть постійні бійки.
2. Напишіть їм дуже простий інструмент, який просто захопить поточну версію та вставить її кудись, щоб вони могли перемотатись до вчорашніх файлів, якщо потрібно. Це можливо, і я зробив це для команди творців DVD (роблячи меню, графіку, всілякі речі) багато років тому з певним успіхом: інструмент, який я написав, був обгорткою PkZip в один клік (ви можете бачити, це було деякий час тому), і він просто застебнув робочий каталог і назвав архів для дати + часу.
3. Візьміть під свій контроль те, що вони виробляють самі. Дайте зрозуміти, що їхні файли повинні бути доставлені програмісту, і вони стануть частиною проекту лише тоді, коли програміст приймає файли: програміст потім перевіряє їх на контроль версій і вмістом керується професійно.

Особисто я думаю, що варіант 3 - це шлях. Це означає деякий біль і роздратування для тих, хто повинен прийняти файли доставки та перевірити їх, але набагато менше, ніж будь-який інший варіант.

Я б також сказав, майте на увазі, що непрограмісти доставлять файли з будь-яким старим іменем файлу, про яке ви можете придумати. Конвенції про іменування їм дивно чужі. Вони дадуть вам файл під назвою "Зображення" або щось подібне, і тоді, коли ви скажете їм, що з ним не так, ви отримаєте файл під назвою "Picture_Final", який має правильну інформацію про 3 помилки. Коли ви це вкажете, ви отримаєте ще один файл, який називається "Picture_NewFinal", а потім (якщо вам пощастить) "Picture_NewFinal2", хоча можливо, що в цей момент вони вирвуть будь-яке відчуття історичного розвитку і назвуть його "Spanner Icon річ ».

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

Сподіваюсь, що допомагає - веселіться!

Якщо є ймовірність, що двом з них потрібно працювати над однією і тією ж ціллю відразу І якщо ви можете впоратися з усією їх роботою в текстових файлах, я б спробував спільні документи Google.

Він має дивовижну можливість редагування / співпраці - на сьогоднішній день найкраще, що я бачив. Вони також мають повну версію і можуть бути експортовані у текстові файли.

Але це два досить великих ifs.

Нехай вони працюють у папці, зберігаючи файли, як зазвичай.

Раз на день (або тиждень тощо) копіюйте вміст цієї папки в backup_dd_mm_yyyy Вихідний код більшості систем займає тривіальну кількість простору, враховуючи простір, доступний в ці дні.

Копія може бути зроблена вами, ними, стороною стороною, інструментом або сценарієм.

Це обмежує втрату до одного дня, дає історію, є прозорою для них.

Не ідеально підходить ні для однієї зі сторін, але відповідь, яка прагне пробити середнє місце.