By the way, this is something that might be worth looking into for the wrapdb webpage... ? Would make a lot of sense, I think, to be able to branch of new version branch from an older one instead of copying files and losing history.
Let's continue discussion here. I agree that solving this is a good idea. Let me try to describe the difficulty.
Each project is a git repository. Each version is a branch. Each revision is computed inside the branch. The code that I wrote just runs BFS and counts number of parent nodes (including starting node) that have upstream.wrap file. Revision is the number of such parents. So you can see, if we just created a new branch it will have revision 1. On each subsequent commit it will increment by one. However if you clone branch it will not reset the revision. I tried introducing [wrap version] tag that would limit BFS from going further, it works, but I am not sure if this is clean enough approach, and when I asked people to use it few times it got ignored. Also it's relatively easy to forget to put this tag.
I have another idea we could try using. If we put version number in upstream.wrap itself, the we can track version change. The trick here would be to make it backward-compatible with older upstream.wrap files without this new field. In case we implement this, revision is number of parent nodes with upstream.wrap files with matching version, if version is not found then just number of parents with upstream.wrap.
@martin-ejdestig wrote
Let's continue discussion here. I agree that solving this is a good idea. Let me try to describe the difficulty. Each project is a git repository. Each version is a branch. Each revision is computed inside the branch. The code that I wrote just runs BFS and counts number of parent nodes (including starting node) that have
upstream.wrapfile. Revision is the number of such parents. So you can see, if we just created a new branch it will have revision 1. On each subsequent commit it will increment by one. However if you clone branch it will not reset the revision. I tried introducing[wrap version]tag that would limit BFS from going further, it works, but I am not sure if this is clean enough approach, and when I asked people to use it few times it got ignored. Also it's relatively easy to forget to put this tag.I have another idea we could try using. If we put version number in
upstream.wrapitself, the we can track version change. The trick here would be to make it backward-compatible with olderupstream.wrapfiles without this new field. In case we implement this, revision is number of parent nodes withupstream.wrapfiles with matching version, if version is not found then just number of parents withupstream.wrap.What do you think @martin-ejdestig?