Add Ability to Track Branching and Merging

Registered by rejon

The concept here is to have a writer upload a file then an editor can edit it, creating a derivative/child of the original, and have that hierarchy remain. If there are larger changes, could even merge back with an authors separate copy. Should first describe this in db, and then add functionality...pretty important...

<rejon> i was talking more about linking files
<rejon> like file10 to file9
<rejon> file10 is a derivative of file9
<bassel> oh
<bassel> yeah you can do same for files
<bassel> but
<bassel> there is no place in the form that identifies a files as derivative from other file
<bassel> so should have like a new table for files and there original files
<rejon> really?
<rejon> yah
<rejon> makes snese
<rejon> original_id, derivative_id
<rejon> no need for key
<rejon> oh, probably a date for update
<rejon> created, updated
<rejon> any other thoughts?
<bassel> rejon you also need to link the current form with another form that has the original_id and derivitave_id
<bassel> it's explained in the end of http://aikiframework.org/wiki/Defining_db_tables_and_fields
<bassel> how to insert into multi tables

I think the necessary fields in a db: unique_key, parent_id, child_id, creation_time, update_time and could add other_parent_id (optional for merges).

My one question is, what to do about if you have version 0 of a file, then version 1, version 2. Would those all be in the same db?

Also,

Blueprint information

Status:
Started
Approver:
rejon
Priority:
Essential
Drafter:
rejon
Direction:
Needs approval
Assignee:
Brad Phillips
Definition:
Discussion
Series goal:
Accepted for trunk
Implementation:
Slow progress
Milestone target:
None
Started by
rejon

Related branches

Sprints

Whiteboard

This is important for the editors.

Could calculate the version numbers by doing query on all the parent_ids and finding all the child_ids. Then arrange based uon creation time. And could find up the chaing by doing vice versa.

Think of this like remixing of cliparts or music, but more like git.

Also, we need to think about what happens if you can delete a work that is a derivative...if there is deletion of a derivative, this breaks the hierarchy...maybe have to keep a record of the upload, but note that the file has been unlinked...but that it did exist. I think that is a reasonable solution.

*Another option that has been proposed is doing all the editing via google docs. For instance, an author submits a work along with a link to that document in google docs. Editors can then make edits and repost the link in the comment field, which would ideally notify the author that changes/comments have been made. Thoughts? —Spencer
* ok, if you guys want to edit pieces that way, that is fine, but for the site, prefer to use the site. all things should flow through the site, otherwise its spraying energy errantly... jon

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.

Subscribers

No subscribers.