[Rock-dev] autoproj commit

[Sylvain Joyeux]

On Mon, Jul 21, 2014 at 10:34 AM, Jakob Schwendner
<jakob.schwendner at dfki.de> wrote:
>> >>       Here comes the neverending question: who has the time ?
>> > To me its quite important that we start soon on this. I could try to
>> > implement the autoproj extensions.
>> > Sylvain, could you quickly outline how you set up your environment for
>> > developing on the gems? Checkout the repo, and do a gem install
>> > everytime you do a change?
>>
>>   1. add tools/autoproj and tools/autobuild to your manifest.
>>   2. run aup tools/autoproj
>>   3. re-source the env.sh (maybe run autoproj envsh, not sure)
>>
>> To create a subcommand, add an autoproj-XXXX (e.g. autoproj-commit) to
>> the bin/ folder. You can have a look at autoproj-snapshot for what you want
>> to do.
>
> Thanks. One question, what is the reason that local package sets are treated differently in the codepath?
> E.g. the snapshot feature makes a difference here, since it writes one into version control info (for local package sets) and one into the overrides. Until now I didn't even know local package sets existed :)
By definition, local package sets do not have a VCS since they are
part of the build configuration repository. They can't be

>
> My plan is to:
> - make autoproj commit write the commitids to a file called 'versions' in the autoproj folder,
>    and create a commit in the autoproj repo with that file.
> - make autoproj aware of the versions file, and load it before the overrides
Don't like that at all. I would really prefer having a uniform way to
overlay overrides. My preferred option so far would be an overrides
folder in which files get loaded in alphabetical order, then having
the version-related files named 00_name_of_version.yml).

The issue with having a version FILE is that you can't layout versions
on top of each other, which is something we will want for the
rock.core / rock stable versioning (i.e. having one file per release
of major package set).

> - autoproj update seems a bit tricky. You don't want it to revert to the commit from the versions file if you have local commits. Maybe the default behavior should be to fast forward if possible, and otherwise don't do anything to the repo.
This is problematic because both behaviours assume to know what the
user really wants to do. If he wants to switch versions, for instance
to go back to an older version, then the behaviour you describe will
screw him. The current behaviour assumed that specifying a commit
meant "I really want to pin this package". Both are bad in some
situations.

I go back to my point that we will need a special tool to switch
between versions. If we do have this tool, then the best is to go for
the behaviour you describe by default and have a way to switch to "I
really really want packages to go back to their specified commits".

In a versioning-scenario, what we are trying to build, we even would
want to reset the local repository HARD to the desired commit when
switching versions instead of creating detached heads. This will
require being careful about safeguarding commits that have not been
pushed.

Sylvain