Skip to content
This repository has been archived by the owner on Apr 11, 2024. It is now read-only.

Doesn't support long text files #57

Open
wheeyls opened this issue Jan 19, 2011 · 3 comments
Open

Doesn't support long text files #57

wheeyls opened this issue Jan 19, 2011 · 3 comments

Comments

@wheeyls
Copy link

wheeyls commented Jan 19, 2011

I'm considering this gem for a version control solution I'm writing. We'll be saving long files in the active record model - including some :medium_text columns.

When I view the database I can see that the "modifications" column is just a "text" field - which I believe cuts off around 64kb in most modern databases. This is too short for my purposes.

Has anyone ever tried to work around this by changing that column type directly?

@wheeyls
Copy link
Author

wheeyls commented Jan 22, 2011

My own experimentation with this has been positive. I've found that simply creating a migration to change the "Modifications" column to mediumtext seems to meet my needs.

My concern now is that when I version a large file or script, that there is a lot of duplication in the database.

For instance, I have file that is about 3000 lines long. If I make a change to one line of that file, then I see both file get saved in their entirety in the modifications column. I thought that there was an element of this that was only versioning changes? Is there something about this that I'm not understanding?

Mike

@wheeyls
Copy link
Author

wheeyls commented Jan 25, 2011

I'm working around this by adding a "patch" column to the model that I am versioning. I no longer version the entire script, I only version the patch.

The patch is generated using the diff-lcs gem. It is very concise and useful - I can create the patch with this:

patch = previous_file.diff(current_file)

The patch is serialized and saved and versioned. When I want to rebuild the file, I step back through the patches:

list = versions.after(version).reverse
content = current_file
list.each do |v|
    content = content.unpatch!(v.changes.patch.last)
end

I was considering creating a fork to put this directly into the plugin - I think that adding an option for :patch, and then modifying revert_to and append_change for patched fields would do it? Or else create before_revert and before_append callbacks to make it easier to add custom processing to columns?

Mike

@safetypins
Copy link

So, you can filter the columns that are versioned? You filter out the 'body' column, and only allow the 'patch' column to be versioned? Is this workaround still working? Has Vestal Versions implemented something similar in the last ~4 years?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants