snapshot support and multiple manifest files

[kwavnet]

First of all thanks for this lovely tool.
Currently we are evaluating alternatives to repo tool and this one here checks almost all the boxes and has readable code (🥳 ), which is a big plus.

Currently we work with a single file manifest, that has floating (just the branch) references to a few of our larger stack of repositories we need to assemble.

Once a change has passed CI we generate a fixed revision monolithic file as a release.
With that in mind #48 would be exactly the missing piece for us to entirely move on from repo.

After reading #235 I'm a bit confused to be honest.

Shall the snapshots be just a local feature?
I mean if the file name of the manifest is static (and I understand the reasoning behind that) do I need to run a second command (like snapshot load <something.yml>) to get to that frozen set again?
Or are those snapshots not meant to be put under version control?

To me the logical consequence (at least for our setup) would be to allow a configurable manifest file name - like manifest.dev.yml and manifest.release.yml.
Unfortunately branching won't do it for us, as, with up to 20 releases a day, we would end up with big pile of branches within a year (something that becomes unmanageable, if you think about that we require each of those releases to be immutable, hence using the branch protection feature of e.g. Github, which needs to be configured).

An alternative, as mentioned, would be to run this second command snapshot load <manifest.release.yml> after the initial init with the "normal" "dev" variant - but I'm not sure how well that goes in real life, considering that in our setup repos come and go, so there might be larger diff between those.

I would be happy if one of the maintainer of this tool could clarify the intent of the snapshot feature.

(btw we are willing to really invest into implementing that)

[lomnido]

Hi @kwavnet ,

'snapshot' feature is no longer there. Do not know why, I have to look for it further.

In regarding of your use-case:
1.) you can use 'apply-manifest' feature that can load and apply any manifest you have even as some extra manifest in your manifest repository.
2.) if you have 20 release a day, then I see your point. So the feature request as I see it here is to allow for Manifest (for Workspace) to configure not only branch, but tag and SHA1 as well. This seems like a good idea. I had to look at it more.

[lomnido]

Also 'apply-manifest' only take care of missing repos and filesystem operations of provided manifest.

It does not switch branch, tag or SHA1 of already existing repos. This may need to be updated as well by extending let us say with '--hard' option in which case even existing repos will get reset/checkout to requested branch, tag or SHA1 from provided Manifest file as well. It is just a thought.

[lomnido]

Hi @kwavnet ,

In regards of my 2nd point of allowing Manifest to be set to Tag or SHA1 and not only to branch:
As I am looking into it, such change to be done properly it may took about 3 months for me to implement (and that is optimistic estimate when everything goes smoothly).