Context Navigation

Autoproj's log, tag, commit and reset

Autoproj is gaining the general ability to save the state of the source code of a complete autoproj installation. The key features are:

the processing of overrides information stored in multiple files in autoproj/overrides.d

the ability to pin package sets

the ability to reset an autoproj project to a state from the past

Pinning (git) repositories. One major change required by all this is how autoproj/autobuild handle pinning (git) repositories (I put git in parenthesis as it applies only to git for now but is more general than only git). The current behaviour was to create a detached HEAD (and complain about it), which is a major headache as working with detached HEADs is really weird in git, and other (D)VCS don't have the concept at all.

Instead of creating detached HEADs, I propose that we reset the target branch (e.g. 'stable') to the specified commit if:

all commits that will be removed from the branch by the reset are present upstream

there are no unmodified changes that would be overriden by the change

From there, the following things are implemented - ASSUMING THAT THE MAIN AUTOPROJ CONFIGURATION ($AUTOPROJ_CURRENT_ROOT/autoproj/) IS UNDER GIT. In all the following items, autoproj/ is this repository.

autoproj auto-logging. Each time autoproj update is executed, autoproj:

takes the current HEAD of autoproj/

adds the current state of the system in autoproj/overrides.d/50-versions.yml

saves the result as a reflog in the autoproj/ repository without modifying anything else (no modification to branches / tags and working copy). The log can be displayed by running autoproj log, or directly with git by running git reflog autoproj. As a reflog, it is automatically pruned by git after a certain amount of time (the default timeout is 30 days I believe)

autoproj tag

takes the current HEAD of autoproj/

adds the current state of the system in autoproj/overrides.d/50-versions.yml

saves the result as a (git) tag in the autoproj/ repository without changing either the working copy or the branches. This allows to save permanently, and optionally publish, an interesting state without interfering with the work of the developer.

autoproj commit

explicitely saves the state of the system in autoproj/overrides.d/50-versions.yml, in the current working copy

if --freeze is given, leaves the versions file in the working copy, otherwise leaves the autoproj/ directory unchanged.

Workflows

The updates-always-break-something situation

The first situation that snapshot aims at fixing is the uncertainty related to running autoproj update. Updating can break the current system (even when working with a Rock release, we all are using the master of a bunch of packages that either come from our private projects or because we develop them within Rock).

The developer should be able to go back to the previous state of its Rock-based project after running updates when he realizes that something is broken.

The let's prepare that demo situation

When preparing a demo, we want to be able to "save" the state of the Rock project every time some project has been made

The workflow would be to branch out from the autoproj/ repository into a "demo" branch and use autoproj commit every time some progress is made.

The It's Working ! Moment

That's a job for autoproj tag.

Releasing Rock

As you may have noticed, all the different tools are basically the generation of a 50-versions.yml file in autoproj/overrides.d plus various manipulation of the git repository state. The Rock release mechanisms would be no different basically:

a new release is a new 'autoproj tag' pushed in rock-core/buildconf

it is also saved as a commit on the 'stable' branch of rock-core/buildconf

switching releases is basically doing an autoproj reset --freeze <RELEASE TAG>, except that we might get the tags from the rock-core/buildconf repository regardless of the repository used for autoproj/.

in addition to 50-versions.yml, we should create a README.md or RELEASE_NOTES.md that can be extracted and displayed to the user when he wants to know about the release (e.g. before deciding to switch)

Creating a release is the process of creating the project/workspace that matches the new release, running autoproj commit and tag and pushing the tags.

Where do we go from there ?

first of all, we need to agree on everything that is above

then, we should re-release rock1408 using the method so that interested rock developers can try it out