The strategy sounds resonable to me.<br><br>However from a high level view wouldn't it make more sense to provide 2 APIs to svk itself:<br><br>1) Access to and locking of the depotmap<br>2) Access to and locking of checkout paths
<br><br>This split would make it easier to refactor the checkout code to store the Data::Hierarchy for a given working copy locally in that working copy (f.e. in a SVK or .svk dir) while keeping the depotmap and depots where they are today.
<br><br>Michael<br><br><br><div><span class="gmail_quote">On 8/18/06, <b class="gmail_sendername">David Glasser</b> &lt;<a href="mailto:glasser@mit.edu">glasser@mit.edu</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
So what I'm trying to implement for SVK's locking strategy (which will<br>be added to internal pod docs) follows. Note that neither SVK nor the<br>patch I just sent fully implements this; I have another patch that I<br>think does but I'd like to test it out on Win32 first.
<br><br>Do people think this is a good locking strategy?<br><br>SVK Locking strategy:<br><br>Note: this is *not* about &quot;mirror locks&quot; or &quot;Subversion locks&quot;: this<br>is about locking access to SVK's statefile ($SVKROOT/config) and
<br>checkouts.<br><br>SVK has an application-level &quot;giant&quot; lock, which is a file<br>($SVKROOT/lock).&nbsp;&nbsp;&quot;Holding&quot; the giant lock means having an open<br>filehandle to it, locked exclusively.&nbsp;&nbsp;The process that holds the
<br>giant lock writes its PID into the giant lock file for informational<br>purposes.&nbsp;&nbsp;The giant lock controls all access to the statefile; SVK<br>should never read or write the statefile without holding the giant<br>lock.
<br><br>When an SVK command is executed, the following sequence of events<br>happens (note that commands like &quot;svk help&quot; and &quot;svk --version&quot; which<br>will never need access to the statefile or checkout are special-cased
<br>to not do any locking):<br><br>* Acquire the giant lock; if this fails for several seconds, die.<br><br>* Read the statefile into memory.<br><br>* Call the command's parse_args method.<br><br>* Call the command's lock method.&nbsp;&nbsp;The command can choose one of three options:
<br><br>** Commands which need to make drastic changes to the statefile<br>&nbsp;&nbsp; (including depotmap changes) should call the keep_giant method;<br>&nbsp;&nbsp; this will make SVK hold the giant lock for the entire command. This<br>&nbsp;&nbsp; should be avoided if possible, especially for commands which take a
<br>&nbsp;&nbsp; non-constant amount of time.<br><br>** Commands which need to access a checkout path (either the actual<br>&nbsp;&nbsp; checkout on disk or its record in the Data::Hierarchy object in the<br>&nbsp;&nbsp; statefile) should call lock on their XD (either directly or through
<br>&nbsp;&nbsp; something like lock_coroot); they may call this on multiple paths<br>&nbsp;&nbsp; if they wish. This dies if the statefile that they have already<br>&nbsp;&nbsp; read in indicates that another process has locked those checkout<br>&nbsp;&nbsp; paths. Otherwise, it marks those paths as locked to this process in
<br>&nbsp;&nbsp; the in-memory Data::Hierarchy of the XD.<br><br>** Commands which don't depend on checkout paths can just do nothing.<br><br>* If the command's locking phase locked any checkout paths, write the<br>&nbsp;&nbsp;statefile out to disk.
<br><br>* Unless the command made a keep_giant call, drop the giant lock.<br><br>* Call the command's run method.<br><br>* If the command was keeping the giant lock, write out the statefile,<br>&nbsp;&nbsp;drop the giant lock, and exit.
<br><br>* If the command had locked any paths, get the giant lock, read in the<br>&nbsp;&nbsp;statefile, merge in any changes to the Data::Hierarchy object *in<br>&nbsp;&nbsp;locked paths only* that the command made, write out the statefile,
<br>&nbsp;&nbsp;and drop the giant lock.<br><br><br>--dave<br><br><br>--<br>David Glasser | <a href="mailto:glasser@mit.edu">glasser@mit.edu</a> | <a href="http://www.davidglasser.net/">http://www.davidglasser.net/</a><br>_______________________________________________
<br>svk-devel mailing list<br><a href="mailto:svk-devel@bestpractical.com">svk-devel@bestpractical.com</a><br><a href="http://lists.bestpractical.com/cgi-bin/mailman/listinfo/svk-devel">http://lists.bestpractical.com/cgi-bin/mailman/listinfo/svk-devel
</a><br></blockquote></div><br>