<div dir="ltr"><div><br></div><div class="gmail_extra"><div class="gmail_quote">On Mon, Sep 8, 2014 at 4:00 PM, Simon Davy <span dir="ltr"><<a href="mailto:bloodearnest@gmail.com" target="_blank">bloodearnest@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">On 8 September 2014 15:40, Matt Bruzek <<a href="mailto:matthew.bruzek@canonical.com">matthew.bruzek@canonical.com</a>> wrote:<br>
> José<br>
><br>
> I just had a conversation about that with the Ecosystems team.  You are<br>
> correct, the revision file in the charm directory is no longer used and we<br>
> can delete those files on future updates.<br>
<br>
</span>So this is interesting, as we are looking to start using the revision<br>
file more explicitly, as part of our automation.<br>
<br>
We deploy from local repositories, with charms in bzr, and one thing<br>
we would like to explicitly know which *code* revision is currently<br>
deployed in an environment.<br>
<br>
So we were thinking to have a pre-deploy step that did "$(bzr revno) ><br>
revision"  in each charm, just before deploy/upgrade. That way, the<br>
revision reported by juju status gives us the exact code revision of<br>
the the current charm. This would pave the way for us to diff a<br>
current environment with a desired one and see what charms need<br>
changing as part of a deploy.<br>
<br>
Does this make sense? Is there some other method of knowing the code<br>
branch/revision a charm is currently running?<br>
<br></blockquote><div><br></div><div>you need to keep in mind the revision file will never match a local charm version in the state server (it will at min be at least one higher than that). This goes back to removing the need for users to manage the revision file contents while in development or pass in the upgrade flag during dev, the need was obviated by having the state server control the revision of the charm.</div><div><br></div><div>i filed <a href="https://bugs.launchpad.net/juju-core/+bug/1313016">https://bugs.launchpad.net/juju-core/+bug/1313016</a> to cover this case for deployer, so it could annotate vcs charms with their repo and rev since local charm revisions are useless for repeatability as their independent of content and determined soley by the state server (with the revision file serving as a hint for min sequence value) and the available charms in the state server are not introspectable.</div><div><br></div><div>cheers,</div><div><br></div><div>Kapil</div></div></div></div>