The tags are created on *your project's* buildconf repository.
On Wed, Jun 25, 2014 at 8:22 AM, Matthias Goldhoorn < [email protected]> wrote: > 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] <[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 > [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 > >
_______________________________________________ Rock-dev mailing list [email protected] http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
