View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 1082 | Composr | commandr | public | 2013-03-17 13:37 | 2015-12-11 03:06 |
| Reporter | Chris Graham | Assigned To | Chris Graham | ||
| Priority | normal | Severity | feature | ||
| Status | closed | Resolution | no change required | ||
| Summary | 1082: Revision Control / Distributed authorship, via git and Commandr-fs | ||||
| Description | Revision control is an important part of enterprise CMS. Git is very popular now, so it makes sense to use git for revision control and hence get the value of all the existing git tools out there, rather than implement something proprietary. CMS industry analysts have also commented how existing ecms's are poor for not doing this already. We want to sync individual Commandr-fs directories with git URLs. The user could set all of Commandr-fs to be under one subpath of a git repository, or have different repositories or paths for different kinds of content (e.g. one for just Wiki+). There needs to be an option to define which file-type(s) you will be synching with (e.g. .doc), so as to stop having every single exported view separately saved into git, hence having a big mess. For example: /var/news -> git://example.com/Demonstratr_site/news [.doc] This would allow people on their own machines to have a git export of git://example.com/Demonstratr_site/news (or git://example.com/Demonstratr_site) and edit news entries as .doc files in LibreOffice, then do a commit when they're done. Their changes would then be synched up to the server. The server would need to be configurable to regularly poll git for changes. It should also have a "force immediate sync" button somewhere. Composr would implement the git synching via having its own webdav URL mapped onto itself somewhere on the server (the server operator would need to configure this, we'd need to provide instructions). Composr would need to put a '.git' directory into each synched webdav directory via some kind of symlink to a local filesystem directory, so that git could actually run out of a webdav directory. Understand that in this arrangement, git is now in a sense the master content server, and in fact multiple Composr sites could link parts of their repository to it for synching. You could also do local non-Composr checkouts from the git repository. If git is enabled, disable the native ".<timestamp>" revision control built into Composr: - Comcode page change system - Template change system - CSS change system Code up a new API to query the git repository for changes, or optionally query the adminlogs table. Replace the Wiki+ change system with this, and also the post history system. Hence now Wiki+ and post history use a new Composr revision control API, which subjugates to git if required. | ||||
| Tags | No tags attached. | ||||
| Attach Tags | |||||
| Time estimation (hours) | 32 | ||||
| Sponsorship open | |||||
| child of | 1090 | Resolved | Chris Graham | WebDav for Commandr-fs |
|
|
Immediately before an edit form is shown, we'd need to do a git pull, to reduce chance of conflict. We should have an overwrite-on-conflict rule (merge being disabled), as conversions would make merging very difficult. Composr should force sync on all adds/edits/deletes. |
|
|
This is over-complex. No changes are needed to allow git to be run for a particular Repository-fs directory. You could just make a directory, put a symlink into it to a webdav mounted path, and then initialise git for that directory. Then you manually commit each time you finish making major changes within Composr. That is reflective of a pretty typical git workflow for a developer. You're not supposed to have commits for each individual change, it's supposed to be change-sets. |
