Long-term package revision maintenance

[Gary Thomas <gary@mlbassoc.com>]

I've been running local PR servers for my builds.  This works
quite well, as long as I don't touch my build trees.

What's the best way to manage versions long-term?  i.e. if I
have a deployed system that I build today, but may not touch
for a long time (years?) and I might not want to keep my build
trees for that long.  If I just blow away the build tree, the
next time I build for that target, all of the version info will
be lost.  I'd like to be able to pick up where I left off.

It it safe enough to just save .../cache/prserv.sqlite3?  or
is there a better way?  I tried the bitbake-prserv-tool export
but I'm not sure it does what I want.  In particular, I don't
plan on saving the sstate info and will probably just expect
to rebuild from scratch.  When I ran the export, I see things
like this:
   $ grep bash PR-list.conf
   PRAUTO$bash-completion-2.1-r0$ppce500v2$5044c7315caa9edef95defcc20bdf74a = "1"
   PRAUTO_bash-completion-2.1-r0_ppce500v2 = "1"
   PRAUTO$bash-4.3.30-r0$ppce500v2$03b7364b0d93910fee2eddf1f2c83f4b = "1"
   PRAUTO_bash-4.3.30-r0_ppce500v2 = "1"

So, if I import this file into a new build tree, will it properly
track that the next revision of bash should be r2 (assuming that
its signature changes and r1 if it doesn't change)?  Is it sufficient
to export the PR list when I'm packing the project up and then import
it back when I need to resume?  I really want to be able to keep a
package feed that I can manage over time without having to preserve
the build tree that was used to create it.

Thanks for any advice

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------