Only tag or commit is captured, but not branch and remote about autoproj HOT 9 CLOSED

As far as I understand, you are pointing to multiple problems:

1. the remote in the autoproj configuration is not the remote in which the pinned commit is (i.e. the pinned commit is not on the remote)
2. the remote branch might disappear
3. not be the one the commit is in.

At snapshotting time, 1. and 3. should IMO generate an error. If you mean to track another repository or branch, then do it explicitely. Starting to have snapshots that track other repositories is even more dangerous as you might think that you are tracking e.g. the official repository X (and thus that the repo will not disappear) but the snapshot will track repository Y.

At update time, all three should go into a fallback mode where they do a git remote update and check whether the commit is available locally (best effort to repair a broken situation)

from autoproj.

Not sure I understand the difference between 1 and 3 for snapshot. Regardless, the direction seems about right. But, I would really like to snapshot the remote as well. How about putting things that are not on the official repo into a separate file e.g. 60-clones. This would really make things a lot easier, especially with our new workflow of having PR for development.

from autoproj.

It would make snapshotting a lot easier, but would make sure that the snapshot can be reproduced a lot harder IMO.

To me, auto-tracking the clone is a sure way to get a snapshot that you can't reproduce because you forgot it depended on the clone and then deleted the clone. If you want to make it easy to integrate the PR branches / clones, then let's make it a separate tool and have snapshotting generate an error.

Finally, auto-snapshotting the clone will break using autoproj status to check which PRs are merged and which are not. The point of PRs is to get code merged in the final repository and I personally have very ingrained in my workflow to use autoproj status to check what got merged and what is still pending.

from autoproj.

1. was missing a few words ... I meant:
   1. the remote branch is not the one the commit is in.

from autoproj.

Hence the proposal to treat the clones differently, by putting the version information in a separate file (overrides.d/60-clones). We could then have additional functionality in autoproj for tracking merge status of PR. The reason I would like to have the tracking of clones is that in a project team, you want to share the clones as well. I for example also use autoproj to sync my different machines. With manually tracking the clones this really is a hassle.

from autoproj.

Just so that you know:

• for now, I won't treat the clones differently, because it would be very awkward API-wise. We can always modify it later on
• I'm disabling the resolution to tags by default (but leave an option to enable it), because ensuring that the remote "is the right one" requires to access the network (a.k.a. slow). For remote commits, I assume that what is in autobuild/remotes is up-to-date.

from autoproj.

Ok. Should this already be in the code?

from autoproj.

Nope. Needs testing.

from autoproj.

This has been implemented in various ways in v2

• autoproj versions and status will try to find a branch that contains all the local commits. status warns the user that the local branch is not the branch on which everything's present (and advises to add an override)
• autoproj generally created remotes for all the package sets that override the packags. E.g. if I have a fork of rtt in my 'sylvain' package set, I get three remotes:
  • orocos.toolchain # the original remote
  • sylvain # the fork
  • autobuild # the current importer setting
• autoproj show shows all overrides
• status accepts the --mainline argument that defines what we compare against (in the example above, using --mainline=orocos.toolchain would compare the status in sylvain with the state in orocos.toolchain. In addition, --mainline compares with the definition without any override.

For special github support (e.g. PR support), one would need to create an autoproj plugin.

from autoproj.