On Sun, Mar 2, 2014 at 3:31 AM, Lieven Moors <[email protected]> wrote:
> On Sat, Mar 01, 2014 at 06:16:26PM -0800, J. Liles wrote: > > On Sat, Mar 1, 2014 at 6:54 AM, Lieven Moors <[email protected]> > wrote: > > > > > On Thu, Feb 20, 2014 at 11:47:12PM +0100, Lieven Moors wrote: > > > > > > Yes. The only reason the snapshot would be out of sync with the > > > history is > > > > > > if non-timeline is closed abnormally. If this happens, upon the > next > > > > > > opening, non-timeline will load by replaying the entire history > > > instead of > > > > > > utilizing the outdated snapshot. You can detect this scenario in > your > > > > > > scripts by comparing the file timestamps. > > > > > > > > Sorry to reply to myself, but wouldn't it be best to add this to the > > > > remove-unused-sources script? I had a quick look, but it doesn't > seem to > > > > compare file timestamps, in order to decide for $ONLY_COMPACTED... > > > > > > When thinking about it, this still wouldn't solve my problem. > > > I've been making commits in git while non-timeline was running. > > > In that case the history file would contain information that is > > > needed to clean up unused sources. > > > > > > So for me it would be very useful if there would be an option to the > > > non programs, that would just replay the journal, make a snapshot, and > > > quit. > > > Also, that would make it possible to use the remove-unused-sources > script > > > in all circumstances. > > > > > > But I can understand if you wouldn't care too much for this specific > > > use case. > > > > > > > > So, are you hoping to do this after every time you close a session or > > something? Personally, I only use the remove-unused-sources script on > > As I said, I use git to keep track of different versions of the song. > When I do a git-commit with timeline running, I have a commit where the > session needs compaction. What I want to do is checkout all git-commits > one by one, make sure the timeline session is compacted, adapt the > remove-unused-sources script to store the list of unused sources for that > commit, add them to the list of unused sources of the previous commit, > and so on... (or maybe collect a list of used sources...) In the end > I have a list of all sources that can be removed, without breaking the > "commit" sessions. > > > session that A) I know involved a lot of extra takes and B) is completely > > finished to the point where I feel complete confidence in deleting the > > unused takes and their sources. And this brings up another point. If you > > have old takes, their sources will still be 'used' until you delete the > > takes (but if you're not using the 'takes' feature, then what you see on > > the timeline is all that will be considered 'used' after compaction). > > Yes, I know that. I might make a script to remove unused takes as well, > but then I would also need to make sure the session is compacted. > Otherwise, at least for my git sessions, I would need to take the history > _and_ snapshot file into account, which IMHO is not a very elegant > solution... > > > > > I should also point out that the format of the 'history' file is very > > simple and it would be fairly easy for someone to write e.g. a perl > script > > that parses it line by line and tracks the creation/deletion of regions > to > > identify the final set of in-use files. > > Yes, I've studied the history and snapshot files, and they are very simple. > I do want to write scripts, but I'm not sure if I'm prepared to parse > the history file as well. > > > > > I might be able to add a commandline option to run the compaction > operation > > and then exit, but ensuring that it works without opening the GUI might > > take some effort. > > If you do, I'll be a happy bunny ;-) > > greetings, > > lieven > > Well, one thing I can think of that might help is having non-timeline update the snapshot upon NSM save event, which I presume you're issuing before all this git commiting/scripting happens? That way the snapshot would be up to date at the time of the commit, and then the script could be modified to allow working off of the snapshot instead of the history. Another concern that just came to mind is the fact that git might be obliterating the timestamp relationship between the history and snapshot files in this case--which could have unexpected results.
