Дополнительно
Соглашения об именовании файлов при пересылке файлов по электронной почте?
Я часто редактирую черновик рукописи с соавторами, отправляя черновики документа туда и обратно по электронной почте. В зависимости от того, с кем я работаю, облачные решения для совместной работы не всегда подходят.
После некоторой работы туда-сюда появляется множество промежуточных черновиков, поэтому многие мои соавторы либо ставят инициалы, дату или нумеруют рабочий документ, когда мы отправляем его на редактирование. Некоторые вообще ничего этого не делают. Мне интересно, существует ли правильный способ "называть" документ при совместной работе по электронной почте. Существует ли консенсус по поводу лучших практик именования файлов при совместном редактировании по электронной почте?
29
3
Не использовать контроль версий - это плохо.
Вы можете использовать облачные решения, даже если некоторые сотрудники против них. Все, что вам нужно сделать, это: Загрузить и отправить по электронной почте облачную версию тем сотрудникам, которые отказываются использовать облако, и загрузить все, что они пришлют в ответ.
Ключом к современному контролю версий, такому как git, является знание родительских документов документа. Таким образом, вы должны быть в состоянии восстановить, какой была непосредственно предыдущая версия.
Поэтому попросите их пометить свою версию, как минимум, номером и именем новой версии, а в идеале - добавить, из какой версии они ее создали (или из нескольких, если это было слияние)
Таким образом, как минимум, OP может использовать -.-.txt.
Таким образом, можно сделать вывод, что rollingstones-4.2-PK.txt был получен PK из (вероятно) 4.1. Также как и rollingstones-4.2-IR.txt также, вероятно, имеет 4.1 в качестве родителя, но изменен независимо кем-то другим. Когда вы объединяете версии с одинаковым номером, вы можете опустить автора и просто присвоить ей следующий номер, например, если rolling stones-4.3.txt является объединением предыдущих.
Если вы можете себе это позволить, а люди дисциплинированы, было бы полезно помечать непосредственного предшественника: rollingstones-4.4-UM-from-4.3-PK.txt. Это немного неуклюже и плохое подражание современным VCS, таким как git, но это позволяет вам вывести родителя(ей) текущей версии, что в конечном итоге все, что вам нужно.
Чтобы облегчить это, попросите людей, непосредственно после загрузки последней версии, дублировать ее и немедленно изменить ее имя, чтобы отразить родительские права загруженной версии.
tl;dr: По моему личному мнению, лучшим вариантом является сохранение имени файла в любое время.
Вот мои доводы. Имя файла говорит нам, какой цели служит документ, какую информацию он содержит. Мета-информация (кто автор, когда была сделана последняя правка) сохраняется в свойствах файла или в специальных полях в самом файле. История правок традиционно ведется с помощью какой-либо системы контроля версий (СКВ).
В вашем случае в качестве VCS используется электронная почта. Электронные письма имеют временную метку, и ваш почтовый клиент позволяет сортировать письма по этой дате. Электронные письма также дают вам информацию о последнем авторе. Если люди отправляют свои правки, отвечая на письмо с указанием версии, с которой была сделана правка, почтовый клиент хранит все дерево правок, как и git, позволяя вам найти родителя для каждой версии. Дерево писем - это прямой эквивалент дерева git. Возможно, вы захотите создать фильтр, чтобы помещать все письма с прикрепленным файлом в специальную папку, чтобы отделить их от остальных сообщений. В остальном, электронная почта - это уже минималистичный и неполный (например, без автоматического слияния), но работающий VCS.
Поскольку у вас уже есть VCS, изменение имен файлов для кодирования одной и той же информации является ненужным и неудобным, и его следует избегать.
PS: И само собой разумеется, электронная почта - это гораздо более плохой VCS по сравнению, например, с git, поэтому вам следует, по крайней мере, предложить своим коллегам попробовать использовать лучшую систему для совместной работы.