[nama] Re: Serialization stuff
- From: "S. Massy" <lists@xxxxxxxxxxxx>
- To: nama@xxxxxxxxxxxxx
- Date: Tue, 27 Sep 2011 18:40:14 -0400
On Sun, Sep 18, 2011 at 09:53:47AM -1000, Joel Roth wrote:
> Regarding RCS, here are a couple ideas
>
> 1. I think RCS is a great way to handle projects, and gives
> a huge advantage over the simpler save mechanisms
> of most other DAWs.
So much so, that I wonder it wasn't thought of before. Do you happen to
know if any DAW offers something similar (the way office suites offer
revision control).
>
> 2. If we simply track State.*, polished_mix would be a
> branch.
>
> nama> save polished_mix
>
> would create a branch, the file names State.* would be unchanged.
I've never used any RCS very extensively, and haven't at all for any
kind of "development" purpose for years and years... This said, I
thought branches were more for parallel development, like a stable and a
devel branch. In such terms, I would see polished_mix more as a "major
milestone" than a branch. Each unnamed save could be an increment on the
named save (a minor update), and named saves would start a new milestone
line. Branches would be more for concurrent mixes, such as an
instrumental and a vocal mix, which is not infrequent. We could even
have an autosave mechanism which could create timestamped subincrements
on the last minor save.
>
> 3. For the user, it might be convenient to have a state file
> polished_mix as well. (It also might invite some confusion
> if a user expected to be able to edit it directly. We could
> discourage that with read-only permissions or a warning
> at the top of the file.)
What would be the possible reasons other than for debugging/hacking
purposes for a user to actually want to edit the state file by hand? We
could always allow a user to "check out" a given state file.
>
> 4. What do we do about .namarc, asoundrc, jack parameters, etc?
> + if we don't track them, do we have a sufficiently
> reliable representation of the project?
I don't really see a reason to track those as they are little likely to
change after work begins; and, if they do change, they should probably
affect every stage of the project anyway.
> + if we do track them, our RCS gets very complicated
> + in general .namarc is project independent
> + but specifics (such as Ecasound command-line arguments) could change
> in a project
> + we have code (long unused) for per-project namarc
> + project-specific namarc may be confused with ~/.namarc,
> modifying latter won't help if there is a
> ~/nama/project/namarc
I think there should be a project-specific config file to override
certain parameters from .namarc (I'm thinking bit depth and frequency of
workfiles here, but eventually maybe latency compensation also). Those
project-specific files definitely should not be called namarc, though.
> + maybe we need some way to archive a project, saving
> the state of all relevant files, so that later
> housecleaning does not break old project.
That definitely would be very useful, though I guess tar could do the
job just fine.
Cheers,
S.M.
Other related posts:
