<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">I think this discussion is going the wrong way. Instead of looking at the technical how, we should be looking at the how it is going to be used</div><div class="gmail_quote">
<br></div><div class="gmail_quote">Scenario 1: normal development workflow. The goal here is to be able to rollback to a known working state, and save these states. The states don't really have a relationship. They are just ways for each developers to save a known-to-work system so that one can rollback to it.</div>
<div class="gmail_quote"><br></div><div class="gmail_quote">Scenario 2: prepare a release to customer, or demo. In this case, the goal is to converge to a working demo. The working system *will* be pinned to state X at a point in time and then slowly advanced to the point where the system works.</div>
<div class="gmail_quote"><br></div><div class="gmail_quote">In my opinion, we should be using tags for (1) since the states have no relationships between each other. One developer can very well commit a state that is *older* than a state that already has been pushed, using a branch is harmful.</div>
<div class="gmail_quote"><br></div><div class="gmail_quote">However, (2) is a typical branch scenario. The branch is made of a set of snapshots that allow to progress to a common goal (a working demo / ready to release system). Happily for us, the branch *is* the currently checked-out buildconf branch.</div>
<div class="gmail_quote"><br></div><div class="gmail_quote">To reflect the two different cases, I would think of adding</div><div class="gmail_quote"> autoproj tag -> create a tag with the current state in autoproj/</div>
<div class="gmail_quote"> autoproj commit -> update the current buildconf to pin the current state and commit in autoproj/. The workflow is the traditional update, fix bug, commit</div><div class="gmail_quote"><br></div>
<div class="gmail_quote">The command that would allow to go back to any saved state</div><div class="gmail_quote"> autoproj rollback -> argument can be a time/date, tag name or commit ID.</div><div class="gmail_quote">
<br></div><div class="gmail_quote">The issue of getting back in time when adding a commit ID / tag ID can easily be fixed in the git importer. We just have to check that all commits in HEAD are also in the remote branch before we reset the branch. "autoproj rollback" would then make sure that all packages that have been rolled back will be rebuilt at the next autoproj build (whether a rebuild or a force-build, I am not sure).</div>
<div class="gmail_quote"><br></div><div class="gmail_quote">On Tue, Jun 24, 2014 at 5:51 PM, Steffen Planthaber <span dir="ltr"><<a href="mailto:Steffen.Planthaber@dfki.de" target="_blank">Steffen.Planthabt er@dfki.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">I also like this approach, as one could just revert an autoproj update<br></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
in case it does not compile. But I still like the idea of having all<br>
build configuration related stuff in one single repository. That makes<br>
it easier to find certain snapshots or the snapshots at all.<br></blockquote><div>Agreed. An easy one would be to replicate what "git stash" does so that we are sure of not pushing anything "by mistake".</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="">> - add an "autoproj commit" command that commits the current state with<br>
> a commit message *as a tag* in the repository. This way, there is no<br>
> branch and therefore no problem with merging. Pushing all snapshots<br>
> means doing git push --tags. Of course, autoproj commit would have the<br>
> ability to store any state from the reflog.<br>
<br>
</div>I'm assuming "the repository" is the buildconf. Going back to a normal<br>
state after a snapshot was done, means reverting changes in quite some<br>
files: overrides.rb, removing local filenames from source.yml for<br>
import_packages, can't remember more.<br>
As long of course, as there is no special branch for snapshots ;-)<br></blockquote><div>The only two files that autoproj snapshot currently modifies is overrides.yml and manifest. With the idea of adding an overrides.d folder that I mentioned earlier, we would even not have to modify overrides.yml. We then add a way to pin the package sets directly in overrides.yml and we won't have to modify the manifest. In the end, the difference between a buildconf and a snapshot would be a single (new) file in autoproj/overrides.d</div>
<div><br></div><div>Sylvain</div></div></div></div>