[Rock-dev] autoproj commit

[Jakob Schwendner]

> 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
I understand they are in the VCS of the buildconfig, instead of getting their own repo, no? 
Also, does that have any implications on the packages that they refer to? They can be (and usually are) in a VCS, no?

> > 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).
I am not sure I understand all of this. Having cascading overrides is in principle fine for me. Although this can probably get a bit complex to manage from the user side.
The rest is a bit confusing to me. Did you want to have an overrides/versions file per package set? I admit we haven't fixed the entry points for the version, or how to update to a new release. However, I did not see the versions index to be the tool for it. Could you maybe outline what you had in mind here?

> > - 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".
By special tool you mean something other than autoproj update? I would have said, fast forward and no revert as default, and have a switch that also does the revert.

> 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.
Would be covered by the switch as well in my opinion. Using it wrongly will only cost you some time to recover in the reflog, no?