[Rock-dev] Flavours, freezes, updates

Sylvain Joyeux bir.sylvain at gmail.com
Tue Jun 24 16:51:02 CEST 2014


While I like the general workflow very much, I am totally against
committing automatically to the snapshot branch. If you do so, you are
actually committing (1) without any message that explains something and (2)
something that you do not know yet whether it works or not. Moreover,
merging is going to be ... interesting.

So, I would update the proposal to:
 - have the equivalent of a reflog, that is a list of snapshots that are
*local* to the current user (i.e. not part of any public repository) so
that *the developer who remembers what he did in the last days* has the
ability to go back to any state he has seen before in its current
repository. This is updated automatically by autoproj each time 'autoproj
update' is executed and can be re-bootstrapped by pointing to the source
repository while bootstrapping (e.g. autoproj bootstrap --snapshot
/path/to/original:snapshot_id)
 - 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.
 - add an "autoproj snapshots" command that presents these tags in
historical order with commit messages (kind of a git log of history tags)
 - bootstrapping the right snapshot would be as easy as adding a
tag=<tagname> to the bootstrap line. The script could be easily generated
by using the "current" bootstrap.sh as a template.

Sylvain
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20140624/6a1612f9/attachment-0001.htm 


More information about the Rock-dev mailing list