Как кодировать простую систему управления версиями?

Для схема базы данных, вам, вероятно, понадобится два набора информации: файлы и версии файлов. Когда сохраняется новый файл, также создается начальная версия. Последняя утвержденная версия должна быть сохранена явно, в то время как новейшая версия может быть выбрана из таблицы версий (либо путем поиска самой высокой версии, связанной с файлом, либо самой новой даты, если вы сохраняете, когда они были созданы)

files(id,name,approved_version)
file_versions(id,fileId)

file версии затем могут быть сохранены с использованием их идентификаторов (например, '/ fileId / versionId' или '/ fileId / versionId_fileName') на сервере, с их исходным именем, сохраненным в базе данных.

Ознакомьтесь с ProjectPier ( первоначально ActiveCollab ). У него есть система, аналогичная этой, и вы можете посмотреть их источник.

Вы можете почерпнуть вдохновение из там .

---

Относительно вашего комментария:

Что касается структуры базы данных, вы можете попробовать такую ​​структуру (MySQL sql) :

CREATE TABLE `Users` (
       `UserID` INT NOT NULL AUTO_INCREMENT
     , `UserName` CHAR(50) NOT NULL
     , `UserLogin` CHAR(20) NOT NULL
     , PRIMARY KEY (`UserID`)
);

CREATE TABLE `Groups` (
       `GroupID` INT NOT NULL AUTO_INCREMENT
     , `GroupName` CHAR(20) NOT NULL
     , PRIMARY KEY (`GroupID`)
);

CREATE TABLE `Documents` (
       `DocID` INT NOT NULL AUTO_INCREMENT
     , `GroupID` INT NOT NULL
     , `DocName` CHAR(50) NOT NULL
     , `DocDateCreated` DATETIME NOT NULL
     , PRIMARY KEY (`DocID`)
     , INDEX (`GroupID`)
     , CONSTRAINT `FK_Documents_1` FOREIGN KEY (`GroupID`)
                  REFERENCES `Groups` (`GroupID`)
);

CREATE TABLE `Revisions` (
       `RevID` INT NOT NULL AUTO_INCREMENT
     , `DocID` INT
     , `RevUserFileName` CHAR(30) NOT NULL
     , `RevServerFilePath` CHAR(255) NOT NULL
     , `RevDateUpload` DATETIME NOT NULL
     , `RevAccepted` BOOLEAN NOT NULL
     , PRIMARY KEY (`RevID`)
     , INDEX (`DocID`)
     , CONSTRAINT `FK_Revisions_1` FOREIGN KEY (`DocID`)
                  REFERENCES `Documents` (`DocID`)
);

CREATE TABLE `M2M_UserRev` (
       `UserID` INT NOT NULL
     , `RevID` INT NOT NULL
     , INDEX (`UserID`)
     , CONSTRAINT `FK_M2M_UserRev_1` FOREIGN KEY (`UserID`)
                  REFERENCES `Users` (`UserID`)
     , INDEX (`RevID`)
     , CONSTRAINT `FK_M2M_UserRev_2` FOREIGN KEY (`RevID`)
                  REFERENCES `Revisions` (`RevID`)
);

Документы - это логический контейнер, а Редакции содержат фактические ссылки на файлы. Каждый раз, когда кто-то обновляет новый файл, создайте запись в каждой из этих таблиц, одну в Revisions, содержащую ссылку на одну, вставленную в Documents.

Таблица M2M_UserRev позволяет связать нескольких пользователей с каждой версией документа.

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

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

Схема базы данных

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

Пользователь сущность :

• userId
• userName

Group entity:

• groupId
• groupName

File entity:

• fileId (последовательность)
  
• fileName (имя, которое пользователь дает файлу)
  
• filesystemFullPath
• uploadTime
• uploaderId (идентификатор пользователя, загрузившего файл)
• ownerGroupId

Document entity:

• documentId
  
• parentDocumentId
  
• fileId
  
• versionNumber
  
• creationTime
  
• isApproved

Каждый раз, когда загружается новый файл, создается запись «Файл», а также новый «Документ». Если этот файл загружается в первый раз, parentDocumentId для этого документа будет NULL. В противном случае новая запись документа будет указывать на первую версию.

Поле «isApproved» (логическое) будет обрабатывать документ как черновик или одобренную редакцию.
Вы получаете последний черновик документа, просто упорядочивая его в порядке убывания номера версии или времени загрузки.

Подсказки

Исходя из того, как вы описываете проблему, вам следует лучше проанализировать эти аспекты, прежде чем переходить к разработке схемы базы данных:

• какова роль «группового» объекта?
• как связаны группы / пользователи / файлы?
• что, если два пользователя из разных групп попытаются загрузить один и тот же документ?
• вам понадобятся папки? (возможно, вы это сделаете; мое решение все еще действует, давая тип «папка» или «документ» сущности «документ»)

Надеюсь, это поможет.

Возможно, существующая версия- Контрольное решение работает лучше, чем собственное? Subversion можно заставить делать почти все, что вы хотите, и это прямо здесь.

Закачка файлов ведется на 1990-ты =) Посмотрите на Google Wave! Вы можете просто построить все свое приложение на основе их «системы контроля версий».

Создание богатой структуры данных в традиционной реляционной базе данных, такой как MySQL, часто может быть трудным, и есть гораздо лучшие способы сделать это. При работе со структурой данных на основе пути с иерархией мне нравится создавать систему на основе плоских файлов, которая использует формат сериализации данных, такой как JSON, для хранения информации об определенном файле, каталоге или целом репозитории.

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

Быстрый пример. Если у нас есть репозиторий, в котором есть каталог и три файла. Глядя на него спереди, он будет выглядеть так:

/repo
  /folder
    code.php
  file.txt
  image.jpg

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

/repo
  */.folderdata*
  /code
    */.folderdata*
    code.php
  file.txt
  image.jpg

Каждая папка .folderdata может содержать свою собственную структуру, которую мы можем использовать для правильной организации данных папки. Каждая папка .folderdata затем может быть сжата для экономии места на диске. Если мы посмотрим на папку .folderdata внутри каталога / code:

*/.folderdata*
  /revisions
    code.php.r1
    code.php.r2
    code.php.r3
  folderstructure.json
  filerevisions.json

Структура папок определяет структуру нашей папки, где файлы и папки расположены относительно друг друга и т. Д. Это может выглядеть кое-что вот так:

{
  '.':        'code',
  '..':       'repo',
  'code.php': {
    'author_id': 11543,
    'author_name': 'Jamie Rumbelow',
    'file_hash': 'a26hb3vpq22'
    'access': 'public'
  }
}

Это позволяет нам связать метаданные об этом файле, проверять подлинность и целостность, сохранять постоянные данные, указывать атрибуты файлов и многое другое. Затем мы можем сохранить информацию о конкретных версиях в файле filerevisions.json:

{
  'code.php': [
    1: {
      'commit': 'ah32mncnj654oidfd',
      'commit_author_id': 11543,
      'commit_author_name': 'Jamie Rumbelow',
      'commit_message': 'Made some changes to code.php',
      'additions': 2,
      'subtractions': 4
    },
    2: {
      'commit': 'ljk4klj34khn5nkk5',
      'commit_author_id': 18676,
      'commit_author_name': 'Jo Johnson',
      'commit_message': 'Fixed Jamie\'s bad code!',
      'additions': 2,
      'subtractions': 0
    },
    3: {
      'commit': '77sdnjhhh4ife943r',
      'commit_author_id': 11543,
      'commit_author_name': 'Jamie Rumbelow',
      'commit_message': 'Whoah, showstopper found and fixed',
      'additions': 8,
      'subtractions': 5
    },
  ]
}

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

Надеюсь, это дало вам некоторое представление, и, надеюсь, это даст пищу для размышлений и сообществу!

хранить постоянные данные, указывать атрибуты файлов и многое другое. Затем мы можем сохранить информацию о конкретных версиях в файле filerevisions.json:

{
  'code.php': [
    1: {
      'commit': 'ah32mncnj654oidfd',
      'commit_author_id': 11543,
      'commit_author_name': 'Jamie Rumbelow',
      'commit_message': 'Made some changes to code.php',
      'additions': 2,
      'subtractions': 4
    },
    2: {
      'commit': 'ljk4klj34khn5nkk5',
      'commit_author_id': 18676,
      'commit_author_name': 'Jo Johnson',
      'commit_message': 'Fixed Jamie\'s bad code!',
      'additions': 2,
      'subtractions': 0
    },
    3: {
      'commit': '77sdnjhhh4ife943r',
      'commit_author_id': 11543,
      'commit_author_name': 'Jamie Rumbelow',
      'commit_message': 'Whoah, showstopper found and fixed',
      'additions': 8,
      'subtractions': 5
    },
  ]
}

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

Надеюсь, это дало вам некоторое представление, и, надеюсь, это даст пищу для размышлений и сообществу!

хранить постоянные данные, указывать атрибуты файлов и многое другое. Затем мы можем сохранить информацию о конкретных версиях в файле filerevisions.json:

{
  'code.php': [
    1: {
      'commit': 'ah32mncnj654oidfd',
      'commit_author_id': 11543,
      'commit_author_name': 'Jamie Rumbelow',
      'commit_message': 'Made some changes to code.php',
      'additions': 2,
      'subtractions': 4
    },
    2: {
      'commit': 'ljk4klj34khn5nkk5',
      'commit_author_id': 18676,
      'commit_author_name': 'Jo Johnson',
      'commit_message': 'Fixed Jamie\'s bad code!',
      'additions': 2,
      'subtractions': 0
    },
    3: {
      'commit': '77sdnjhhh4ife943r',
      'commit_author_id': 11543,
      'commit_author_name': 'Jamie Rumbelow',
      'commit_message': 'Whoah, showstopper found and fixed',
      'additions': 8,
      'subtractions': 5
    },
  ]
}

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

Надеюсь, это дало вам некоторое представление, и, надеюсь, это даст пищу для размышлений и сообществу!

Затем мы можем сохранить информацию о конкретных версиях в файле filerevisions.json:

{
  'code.php': [
    1: {
      'commit': 'ah32mncnj654oidfd',
      'commit_author_id': 11543,
      'commit_author_name': 'Jamie Rumbelow',
      'commit_message': 'Made some changes to code.php',
      'additions': 2,
      'subtractions': 4
    },
    2: {
      'commit': 'ljk4klj34khn5nkk5',
      'commit_author_id': 18676,
      'commit_author_name': 'Jo Johnson',
      'commit_message': 'Fixed Jamie\'s bad code!',
      'additions': 2,
      'subtractions': 0
    },
    3: {
      'commit': '77sdnjhhh4ife943r',
      'commit_author_id': 11543,
      'commit_author_name': 'Jamie Rumbelow',
      'commit_message': 'Whoah, showstopper found and fixed',
      'additions': 8,
      'subtractions': 5
    },
  ]
}

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

Надеюсь, это дало вам некоторое представление, и, надеюсь, это даст пищу для размышлений и сообществу!

Затем мы можем сохранить информацию о конкретных версиях в файле filerevisions.json:

{
  'code.php': [
    1: {
      'commit': 'ah32mncnj654oidfd',
      'commit_author_id': 11543,
      'commit_author_name': 'Jamie Rumbelow',
      'commit_message': 'Made some changes to code.php',
      'additions': 2,
      'subtractions': 4
    },
    2: {
      'commit': 'ljk4klj34khn5nkk5',
      'commit_author_id': 18676,
      'commit_author_name': 'Jo Johnson',
      'commit_message': 'Fixed Jamie\'s bad code!',
      'additions': 2,
      'subtractions': 0
    },
    3: {
      'commit': '77sdnjhhh4ife943r',
      'commit_author_id': 11543,
      'commit_author_name': 'Jamie Rumbelow',
      'commit_message': 'Whoah, showstopper found and fixed',
      'additions': 8,
      'subtractions': 5
    },
  ]
}

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

Надеюсь, это дало вам некоторое представление, и, надеюсь, это даст пищу для размышлений и сообществу!

{
  'code.php': [
    1: {
      'commit': 'ah32mncnj654oidfd',
      'commit_author_id': 11543,
      'commit_author_name': 'Jamie Rumbelow',
      'commit_message': 'Made some changes to code.php',
      'additions': 2,
      'subtractions': 4
    },
    2: {
      'commit': 'ljk4klj34khn5nkk5',
      'commit_author_id': 18676,
      'commit_author_name': 'Jo Johnson',
      'commit_message': 'Fixed Jamie\'s bad code!',
      'additions': 2,
      'subtractions': 0
    },
    3: {
      'commit': '77sdnjhhh4ife943r',
      'commit_author_id': 11543,
      'commit_author_name': 'Jamie Rumbelow',
      'commit_message': 'Whoah, showstopper found and fixed',
      'additions': 8,
      'subtractions': 5
    },
  ]
}

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

Надеюсь, это дало вам некоторое представление, и, надеюсь, это даст пищу для размышлений и сообществу!

{
  'code.php': [
    1: {
      'commit': 'ah32mncnj654oidfd',
      'commit_author_id': 11543,
      'commit_author_name': 'Jamie Rumbelow',
      'commit_message': 'Made some changes to code.php',
      'additions': 2,
      'subtractions': 4
    },
    2: {
      'commit': 'ljk4klj34khn5nkk5',
      'commit_author_id': 18676,
      'commit_author_name': 'Jo Johnson',
      'commit_message': 'Fixed Jamie\'s bad code!',
      'additions': 2,
      'subtractions': 0
    },
    3: {
      'commit': '77sdnjhhh4ife943r',
      'commit_author_id': 11543,
      'commit_author_name': 'Jamie Rumbelow',
      'commit_message': 'Whoah, showstopper found and fixed',
      'additions': 8,
      'subtractions': 5
    },
  ]
}

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

Надеюсь, это дало вам некоторое представление, и, надеюсь, это даст пищу для размышлений и сообществу!

Это не так просто, как кажется. Прочтите эту статью Эрика Синка о последствиях хранения для хранения этих файлов.

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

Start from an existing content management system, done in PHP and MySQL if those are your requirements, such as eZ Publish, or Knowledgetree. For rapid testing of these applications, Bitnami provides quick-to-install "stacks" of these as well (WAMP-stacks on steroids).

Then you can tailor these applications to your organizations needs, and stay up-to-date with the changes upstream.

Недавно я построил простую систему управления версиями для некоторых статических объектов данных. Требовалось наличие «активной» версии и 0 или 1 «ожидающих» версий.

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

VersionNumber (int / long) ActiveVersionFlag (boolean)

Где: -

• только 1 объект может быть ActiveVersionFlag = 'Y'
• только 1 объект может быть Номер версии> «Активная» версия (то есть «ожидающая» версия)

Я разрешил следующие операции:

Клонировать текущую версию.

• Ошибка, если уже существует версия> Номер версии «Активной» версии
• Скопировать все данные в новую версию
• увеличить номер версии на единицу

Активировать ожидающую версию

• Ошибка если указанная версия не является «активной» версией + 1
• , найдите «активную» версию и установите для ее ActiveVersionFlag значение «N»
• установите для параметра ActiveVersionFlag «ожидающей» версии значение «Y»

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

У сервера будет свой корневой каталог данных, и вы можете хранить группы (файлов) в папках с корневой записью метаданных в каждой папке. (Возможно, XML?)

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

Перенести серверы? Заархивируйте и скопируйте. Кросс-платформенный? Заархивируйте и скопируйте. Резервное копирование? Заархивируйте и скопируйте.

Это бэкенд с плоскими файлами, который мне нравится, например, в Mercurial DVCS.

Конечно, в этом небольшом примере файлы .rev могут иметь дату, время, сжатие и т. Д. и т. д., определенные в файле revisions.xml. Когда вы хотите получить доступ к одной из этих ревизий, вы открываете метод AccessFile (), который ваше серверное приложение просматривает в revisions.xml и определяет, как открыть этот файл, предоставлен ли доступ и т. Д.

Итак, вы have

DATA
| + ROOT
| | . metadata.xml
| | |
| | + REVISIONS
| | | . revisionsdata.xml
| | | . documenta.doc.00.rev
| | | . documenta.doc.01.rev
| | | . documentb.ppt.00.rev
| | | . documentb.ppt.03.rev
| | |___
| | |
| | . documenta.doc
| | . documentb.ppt
| | |
| | + GROUP_A
| | | . metadata.xml
| | | |
| | | + REVISIONS
| | | | . revisionsdata.xml
| | | | . documentc.doc.00.rev
| | | | . documentc.doc.01.rev
| | | | . documentd.ppt.00.rev
| | | | . documentd.ppt.03.rev
| | | |___
| | |
| | | . documentc.doc
| | | . documentd.ppt
| | |___
| | |
| | + GROUP_B
| | | . metadata.xml
| | |___
| |
| |___
|
|___

Я думаю, это описывает идеальную систему для управления версиями

http://tom.preston-werner.com/2009/05/19/the-git-parable.html