Solution needed for switching manifests

[smipi1]

When switching between the develop.xml and master.xml, we need to switch the project branches between develop and master as well. The exact behavior on a manifest and therefore project branch when switching between manifests is unknown, and should be properly defined to match what we are trying to achieve.

[GatorQue]

From what I read recently, there were some serious issues in the past when switching between manifest files. But I think the safest approach is to do something like this:
repo init -m other_manifest.xml
repo sync -d
This typically leaves each project in a detached state and I think to some degree prevents the rebase which typically occurs during these switches. At least that was how it was described in the email chain I ran into (which was demonstrating an issue that was eventually resolved). I agree that a few experiments should be performed to confirm this. Is there something else you had in mind or was this what you were thinking?

[smipi1]

Maybe... I would like to see the same behaviour at the composition level as
you would normally see with git flow. With git flow you usually do a git
checkout to switch between master and develop. Maybe a new repo switch
command could provide the same behaviour at the composition level.

On Mon, 1 Feb 2016, 00:29 Ryan Lindeman [email protected] wrote:

From what I read recently, there were some serious issues in the past when
switching between manifest files. But I think the safest approach is to do
something like this:
repo init -m other_manifest.xml
repo sync -d
This typically leaves each project in a detached state and I think to some
degree prevents the rebase which typically occurs during these switches. At
least that was how it was described in the email chain I ran into (which
was demonstrating an issue that was eventually resolved). I agree that a
few experiments should be performed to confirm this. Is there something
else you had in mind or was this what you were thinking?

—
Reply to this email directly or view it on GitHub
#8 (comment)
.

[GatorQue]

What about a repo flow checkout command?

[smipi1]

Do you think we should add something with generic value to the flow sub-command?

A switch can be useful in its own right:
switch = checkout manifest and associated branches, but don't merge / rebase anything.

[GatorQue]

Would this amount to a repo init followed by some type of repo sync? I'm assuming that is what repo flow switch or repo switch would entail.

[smipi1]

Hi Ryan,

I think the workflow will be:
repo init -m develop.xml -u...
repo pull # same as sync, but checks out develop
repo flow init
repo flow feature start...

change and commit stuff.

repo flow features finish...
repo push
repo flow release start...
repo flow release finish...
repo push
repo switch master.xml
repo push --tags
repo switch develop.xml

On Tue, 2 Feb 2016, 02:48 Ryan Lindeman [email protected] wrote:

Would this amount to a repo init followed by some type of repo sync? I'm
assuming that is what repo flow switch or repo switch would entail.

—
Reply to this email directly or view it on GitHub
#8 (comment)
.

[smipi1]

We could perhaps improve the repo push by supporting an optional manifest
spec:
E.g.
repo push master.xml develop.xml --tags

On Tue, 2 Feb 2016, 10:38 Pieter Smith [email protected] wrote:

Hi Ryan,

I think the workflow will be:
repo init -m develop.xml -u...
repo pull # same as sync, but checks out develop
repo flow init
repo flow feature start...

change and commit stuff.

repo flow features finish...
repo push
repo flow release start...
repo flow release finish...
repo push
repo switch master.xml
repo push --tags
repo switch develop.xml

On Tue, 2 Feb 2016, 02:48 Ryan Lindeman [email protected] wrote:

Would this amount to a repo init followed by some type of repo sync? I'm
assuming that is what repo flow switch or repo switch would entail.

—
Reply to this email directly or view it on GitHub
#8 (comment)
.

[GatorQue]

What internally would happen in repo push when you specify an optional manifest spec?

[smipi1]

Equivalent to:

1. Check that there are no uncommitted changes with current manifest state.
2. Perform a repo switch to the specified manifest.
3. Push all branches to remote.
4. repo switch back to previous manifest.

On Tue, 2 Feb 2016, 14:34 Ryan Lindeman [email protected] wrote:

What internally would happen in repo push when you specify an optional
manifest spec?

—
Reply to this email directly or view it on GitHub
#8 (comment)
.

[smipi1]

@GatorQue: We had some topic-drift here. I was using my phone so the context wasn't always clear. The goal was to specify repo switch, and we ended up expanding on repo push. I'll copy the repo push comments to #4 .

[GatorQue]

So am I correct in stating that the optional manifest arguments are to simplify the:
repo push
repo switch master.xml
repo push --tags
repo switch develop.xml

Steps into a single command:
repo push master.xml develop.xml --tags
Such that the develop, master, and tags all get pushed?
That would imply that repo push is only pushing the currently selected branch.

[smipi1]

Yes. Exactly. See #4.