[nama] Serialization rationalization
- From: Joel Roth <joelz@xxxxxxxxx>
- To: nama@xxxxxxxxxxxxx
- Date: Sun, 12 Aug 2012 11:23:18 -1000
Hello Nama Desigers,
Severus(?) Massy reported the other day the he was
getting spurious git commits.
So, I'm in the process of separating out
a few variables into a supplemental
state file for information like $mode->{preview},
which can change without needing a git commit.
It will stay in a file called PeripheralState.json,
that will also contain track cache mapping (for uncache
track) and track comments.
@unversioned_state_vars = qw(
@project_effect_chain_data
%cache_map
%track_comments
$fx->{id_counter}
$setup->{loop_endpoints}
$mode->{loop_enable}
$mode->{mastering}
$mode->{preview}
$project->{bunch}
$gui->{_seek_unit}
$text->{command_history}
$this_track_name
$this_op
);
Raises the question, how are we going to back
up this data. I mean you could stand to lose
track comments and track uncache data
and project-specific effect chains,
without really destroying a project,
Do we allow that failure point?
%cache_map, %track_comments and @project_effect_chain_data
are always accumulating more data. The others change during the
project.
I expect resetting $fx->{id_counter} could trigger some
strange behavior.
If we're using git for everything
else, how would we do this?
While wondering if it might not be overkill
I started to think that we could
have another directory "$project_dir/shadow", managed by git,
with hard links PeripheralState.json
and State.json. That would guarantee being
able to get back to a previous state,
protecting against corrupting the PeripheralState.json,
This would give you a potential mechanism to wind back *all*
system state, and would assure you could return to a precise
system state.
What do you all think?
Cheers
Joel
--
Joel Roth
Other related posts:
