[Rock-dev] Flavours, freezes, updates
Matthias Goldhoorn
matthias.goldhoorn at dfki.de
Wed Jun 25 08:22:27 CEST 2014
Morning,
I don't get the tag thing...
So each "team" is able to create/add tags to the core rock packages?
If not, how are the tags are preserved if for e.g. the system crashes or
needs to be re-installed?
Best,
Matthias
On 24.06.2014 21:09, Sylvain Joyeux wrote:
> 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
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> To reflect the two different cases, I would think of adding
> autoproj tag -> create a tag with the current state in autoproj/
> autoproj commit -> update the current buildconf to pin the current
> state and commit in autoproj/. The workflow is the traditional update,
> fix bug, commit
>
> The command that would allow to go back to any saved state
> autoproj rollback -> argument can be a time/date, tag name or
> commit ID.
>
> 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).
>
> On Tue, Jun 24, 2014 at 5:51 PM, Steffen Planthaber <Steffen.Planthabt
> er at dfki.de <mailto:Steffen.Planthaber at dfki.de>> wrote:
>
> I also like this approach, as one could just revert an autoproj update
>
> in case it does not compile. But I still like the idea of having all
> build configuration related stuff in one single repository. That makes
> it easier to find certain snapshots or the snapshots at all.
>
> Agreed. An easy one would be to replicate what "git stash" does so
> that we are sure of not pushing anything "by mistake".
>
> > - add an "autoproj commit" command that commits the current
> state with
> > a commit message *as a tag* in the repository. This way, there is no
> > branch and therefore no problem with merging. Pushing all snapshots
> > means doing git push --tags. Of course, autoproj commit would
> have the
> > ability to store any state from the reflog.
>
> I'm assuming "the repository" is the buildconf. Going back to a normal
> state after a snapshot was done, means reverting changes in quite some
> files: overrides.rb, removing local filenames from source.yml for
> import_packages, can't remember more.
> As long of course, as there is no special branch for snapshots ;-)
>
> 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
>
> Sylvain
>
>
> _______________________________________________
> Rock-dev mailing list
> Rock-dev at dfki.de
> http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
--
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: matthias.goldhoorn at informatik.uni-bremen.de
Weitere Informationen: http://www.informatik.uni-bremen.de/robotik
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20140625/ee3fa5f9/attachment.htm
More information about the Rock-dev
mailing list