<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 10, 2017 at 2:54 AM, Joshua Root <span dir="ltr"><<a href="mailto:jmr@macports.org" target="_blank">jmr@macports.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">On 2017-8-10 04:59 , Umesh Singla wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Hi<br>
<br>
I was trying to streamline the whole process and I felt the need to have the snapshot as a separate entity just like a reg_entry or a reg_portgroup is, that is, "registry::snapshot" with a bunch of functions like create, get, list_all etc. I think this might help in writing the whole thing from a higher Tcl level.<br>
<br>
But then again, a snapshot is not something coming directly from the database, so I'm not sure how to keep it. Can I get your view on this?<br>
</blockquote>
<br></span>
Well, you already know that my view is that it would be far simpler to store the snapshots as a text-based format, rather than write and modify a large amount of non-trivial C.<br></blockquote><div><br></div><div>I think what Josh means here, is a complete text-based dump of the current state in a file and then using restore, something like what we currently expect our users to do themselves.</div><div><br></div><div>It could be useful in a case when a user wants to completely re-install the OS from scratch and then, a text-formatted file can easily be backed up for use by restore later. We can argue that keeping in registry.db is also similar to keeping in a file, but the interface we are providing a user help migrate are bit different. Because it is not intuitive to take a dump of registry.db manually but running a take_snapshot command is.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
But if you are set on doing this in the sqlite database, the relational way of doing it would be to add:<br>
<br>
1. A table of snapshots, consisting minimally of names and ids<br>
2. A table associating snapshot ids with port ids on a many-to-many basis<br>
<br>
Under this model, the set of currently installed ports would be just another snapshot, albeit one with a special meaning. The activation state of each port would have to move from the ports table and become per-snapshot (maybe stored in the second table?).<br>
<br>
And yes, you would need procedures to manipulate this stuff from Tcl as you suggested above. And the existing code would need to be updated to only remove ports when they are no longer referenced by any snapshot.</blockquote><div><br></div><div>And then again, I am sensing a confusion with the idea of snapshot with Josh, like when he says "remove ports when they are no longer referenced by any snapshot".</div><div><br></div><div>- Umesh</div></div><br></div></div>