[Rock-dev] autoproj commit

Discussion:

Jakob Schwendner

2014-07-21 08:34:47 UTC

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 :)

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
- 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.

I'll try to get the basic concept running first, and then we can see where to tweak.

Cheers,

Jakob

Sylvain Joyeux

2014-07-21 09:22:01 UTC

Permalink

On Mon, Jul 21, 2014 at 10:34 AM, Jakob Schwendner

Post by Jakob Schwendner

Here comes the neverending question: who has the time ?

By definition, local package sets do not have a VCS since they are
part of the build configuration repository. They can't be

Post by Jakob Schwendner
- 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).

Post by Jakob Schwendner
- 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

Jakob Schwendner

2014-07-21 10:03:05 UTC

Permalink

Post by Sylvain Joyeux
On Mon, Jul 21, 2014 at 10:34 AM, Jakob Schwendner

Post by Jakob Schwendner

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?

Post by Jakob Schwendner
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?

Post by Sylvain Joyeux

Post by Jakob Schwendner
- make autoproj commit write the commitids to a file called 'versions' in the

autoproj folder,

Post by Jakob Schwendner
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?

Post by Sylvain Joyeux

Post by Jakob Schwendner
- 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.

Post by Sylvain Joyeux
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?