0

Currently I am working on a blogging system, and I hope that an article can be written together by several registered authors, thus I hope it can provide an simplified git-like version control for the articles, which may provides branching and show differences between two version of articles.

But the problem is, the articles are store in a database table, and git's version control is base on file system, thus I cannot use git directly to implement this functionality.

Could anyone give me some idea on how to design the database tables, the relative API and the high-level logic on this functionality? Thanks.

Stephen.W
  • 1,649
  • 13
  • 14
  • What do you mean exactly by "git-like"? Having versions is not hard but Git has a particular model of versions (a version is the state of everything at a given point in time, not just a sequence of modifications to get you there) and a distributed nature which might or might not be included in what you want. Please [edit] to clarify. – tripleee Jan 29 '19 at 13:47
  • Not storing articles in a database and storing them in Git instead sounds like absolutely the easiest way to get what you seem to be asking for, with no ambiguity as to which Git features exactly you get. – tripleee Jan 29 '19 at 13:48
  • Possible duplicate of [How can I put a database under git (version control)?](https://stackoverflow.com/questions/846659/how-can-i-put-a-database-under-git-version-control) – phd Jan 29 '19 at 15:12
  • https://stackoverflow.com/search?q=version+control+database – phd Jan 29 '19 at 15:12

2 Answers2

0

Basically, I'd :

  • create a table "revision" (with a n-n "parent" relation)

  • add a field "id_revision" to my table, default NULL (OR maybe a special revision id, maybe); and partition this table upon the value of this field, so that previous revisions of an article wouldn't be stored in the same table

  • OR create a table "article_revision" with all the fields of article, plus a field "revision".

You can create hook to save automatically old revisions (maybe in a "pending" revision, then you can commit , i.e. persist the "pending" revision into a numbered one)

But lots of question are to be decided.

You can also store the fields that have changed, instead of the whole row, with a table (table / field / value)

I think you'll have to try different architectures, and test them.

Pierre-Olivier Vares
  • 1,687
  • 15
  • 20
0

This is not a git-related question, really. You just need to implement version control on a database level, which is a project on its own, and generally can be handled between a coder and a database developer. In a way, you just have to do what the git developers did when they needed to use version control for their source code. It's not a simple project; there is no quick and easy answer here.

Vlad
  • 1
  • 1
  • 4