<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Morning,<br>
I don't get the tag thing...<br>
<br>
So each "team" is able to create/add tags to the core rock
packages?<br>
If not, how are the tags are preserved if for e.g. the system
crashes or needs to be re-installed?<br>
<br>
Best,<br>
Matthias<br>
<br>
<br>
<br>
On 24.06.2014 21:09, Sylvain Joyeux wrote:<br>
</div>
<blockquote
cite="mid:CAKDpF4TesHpBemmWzRXctJhLaPaK7EyW_UfD365aE8w4ixP-QA@mail.gmail.com"
type="cite">
<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
moz-do-not-send="true"
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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Rock-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Rock-dev@dfki.de">Rock-dev@dfki.de</a>
<a class="moz-txt-link-freetext" href="http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev">http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev</a>
</pre>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
Dipl.-Inf. Matthias Goldhoorn
Space and Underwater Robotic
Universität Bremen
FB 3 - Mathematik und Informatik
AG Robotik
Robert-Hooke-Straße 1
28359 Bremen, Germany
Zentrale: +49 421 178 45-6611
Besuchsadresse der Nebengeschäftstelle:
Robert-Hooke-Straße 5
28359 Bremen, Germany
Tel.: +49 421 178 45-4193
Empfang: +49 421 178 45-6600
Fax: +49 421 178 45-4150
E-Mail: <a class="moz-txt-link-abbreviated" href="mailto:matthias.goldhoorn@informatik.uni-bremen.de">matthias.goldhoorn@informatik.uni-bremen.de</a>
Weitere Informationen: <a class="moz-txt-link-freetext" href="http://www.informatik.uni-bremen.de/robotik">http://www.informatik.uni-bremen.de/robotik</a></pre>
</body>
</html>