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
[email protected] <mailto:[email protected]>> 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
[email protected]
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: [email protected]
Weitere Informationen: http://www.informatik.uni-bremen.de/robotik
_______________________________________________
Rock-dev mailing list
[email protected]
http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
