Альтернативы для Профессионального контроля версий [закрыто]

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

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

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

Я пришел с некоторыми идеями ...

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

О проекте:

Это система обработки естественного языка (написана на C + Python). Мы наняли некоторых авторов для подготовки материалов для системы на разных языках. И по мере развития программного обеспечения нам нужно, чтобы эти авторы вносили изменения в свои материалы (статьи). Иногда изменения очень малы (словом или двумя), а иногда и большие.

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

когда я впервые представил их ветвлению и слиянию - они выглядели так, как будто я их обижал

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

Так почему бы не объяснить только «зафиксировать» (сохранить) и «обновить»? Два действительно простых понятия. Я уверен, что вы можете объяснить это менее чем за 10 минут.

Если вы действительно хотите использовать отдельные ветви и тому подобное, вы можете выполнить эту часть самостоятельно, не привлекая их к этому.

Весьма неортодоксальным подходом было бы просто использовать Dropbox . Попросите авторов сохранить файлы в каталоге dropbox, и вы получите бесплатное управление версиями и резервное копирование. Плюс, в принципе, нет никакой кривой обучения для авторов.

Для git звучит так, как будто в конце концов вы в конечном итоге предоставите авторам правильные версии веток, так что просто поместите репозиторий git в выпадающий список и обработайте ветвление и слияние для авторов.

По правде говоря, ответ в вашей редакции: «Мы наняли некоторых авторов» - иногда вы просто должны быть чертовски мыслящими ... они хотят ваших денег, они должны делать то, что вы хотите, при условии, что то, что вы хотите, не является необоснованным.

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

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

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

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

Третьи лица отправляли мне по электронной почте zip-файл своих файлов проекта каждый день, и я проверял их. Я установил для них отдельную рабочую область проекта и учетную запись svn и разархивировал файлы в эту рабочую область, переписав то, что было там, а затем выполнил регистрацию под этой учетной записью.

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

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

SparkleShare - это клон dropbox -клона, я думаю, что он соответствует вашим потребностям.

SparkleShare создает специальную папку на вашем компьютере. Вы можете добавить удаленно размещенные папки (или «проекты») в эту папку. Эти проекты будут автоматически синхронизироваться как с хостом, так и со всеми вашими коллегами, когда кто-то добавляет, удаляет или редактирует файл.

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

большой

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

Не так здорово

• Полные компьютерные резервные копии
• Хранение вашей фотографии или музыкальной коллекции
• Большие двоичные файлы, которые часто меняются, например, проекты редактирования видео ...

Обновление (ноябрь 2015 г.) : проект, похоже, заброшен (последний выпуск от апреля 2014 г.).

Если вы можете предоставить готовое рабочее пространство с прозрачным использованием VCS, они будут использовать VCS. Не учите непрограммистов использовать VCS способом программиста

Просто найдите редактор со встроенной VCS-поддержкой, настройте его и покажите дополнительные простые шаги в своих работах.

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

Редактирование : найдено альтернативное решение: EasySVN , который при правильной настройке отслеживает рабочую копию и выполняет автокоммит и автоматическое объединение, позволяя использовать любой инструмент разработки для конечного пользователя и любых форматов документов.

Как насчет настройки WebDAV ?

Он будет автоматически обрабатывать прямую историю версий для них. Все, что им нужно сделать, это подключиться к серверу, как если бы это был сетевой диск, и каждое сохранение будет коммитом.

Гугл документы

Документы Google могут делать то, что вы хотите. File > See Revision Historyпозволит вам отслеживать изменения.

У вас также есть проблема передачи файлов назад и вперед, о которых заботятся бесплатно; просто поделитесь документом со всеми.

Наконец, это легко использовать; авторам даже не нужно знать, что происходит версионирование.

ОС Агностик

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

или же

Используйте основанную на WebDav файловую систему, которую вы можете смонтировать на их машине, и пусть сервер сделает gitвсе прозрачно.

OSX / Linux

Напишите плагин FUSE на основе Python, который берет файлы и фиксирует их в git. Затем они могут просто открыть и сохранить из смонтированной файловой системы прозрачно. Есть некоторые ресурсы FUSE для Windows , но, вероятно, их даже не стоит обманывать.

Windows

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

Ах, радости не-кодеров Я бы посоветовал создать для них git / mercurial среду. Скажите им, чтобы сохранить все в формате, который может обрабатывать репо. С tortoisegit или tortoisehg им не нужно знать, как работает репо. Они просто проверяют, есть ли в каталоге проекта восклицательный знак, щелкают правой кнопкой мыши по файлу-нарушителю и нажимают кнопку фиксации. Напечатайте краткий обзор изменений (они писатели, верно?), И все готово!

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

Как насчет Share Point? Я знаю, что это не популярно в мире разработки, но если ваши авторы используют Windows в качестве ОС, она будет работать хорошо, и они не будут знать, что они используют контроль версий (большой плюс для моей работы).

Это решение также не дает им иметь дело со всем, что может их сильно напугать, так как кажется, что они пугливы в отношении новых вещей.

Не могли бы вы установить инструмент, который следит за файловой системой, в которой авторы сохраняют свои файлы, и позволяет ли ему делать автоматическую фиксацию при каждом сохранении?

Если вы поместите его в общий сетевой ресурс, вы можете выполнить всю настройку, не привлекая их вообще; но каждый раз, когда они предоставляли обновленную версию для вашей команды, она добавлялась в git для вас.

Вы смотрели на пластик СКМ. Они пытаются сделать его проще в использовании

Если вы просто хотите создавать резервные копии с версионной версией, вы можете использовать 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.

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

Но это два довольно больших случая.

Пусть они работают в папке, сохраняя файлы как обычно.

Один раз в день (или неделю и т. Д.) Копируйте содержимое этой папки в backup_dd_mm_yyyy. Исходный код большинства систем занимает тривиальное количество места, учитывая пространство, доступное в наши дни.

Копия может быть сделана вами, ими, третьей стороной, инструментом или сценарием.

Это ограничивает потери одним днем, дает историю, прозрачна для них.

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