On Thu, 2013-09-12 at 10:59 -0700, Hanchett, Paul wrote: > Why not use tags to mark a particular release, rather than the object > ID in the manifest file? I see several advantages: > * You get a single value that can be handed to gbs/obs to pull > all of the packages as of a particular point in time; new > commits have no impact on the git tag (unlike the branches we > use now.) In fact, you might not even need manifest > files........ > * Now, it becomes dead easy to *see* in each repository the > version that was actually released. Placing tags for other > significant events makes those visible in every repository. > I'm sure there are other advantages. Is there a down side? (I'm > relatively new to git...)
I am not an expert in the area, let me CC Alexander. But I believe it is not easy to tag all the repos, and then make sure individual package maintainers do not accidentally remove the tag, or change it. Commit ID's are more persistent. Tagging is less reliable. And yes, I do see why you do not want to use SRPMs as Joel suggested. Git trees with the history and the right commit ID for the release is just a lot more usable than SRPMs. It is easier to check the code then, do 'git log -p' or 'git blame', quickly hack the code and commit, etc. I personally really do not consider SRPMs to be useful for anything. For me SRPM is just a temporary thing between the git repo and the RPM. -- Best Regards, Artem Bityutskiy _______________________________________________ General mailing list [email protected] https://lists.tizen.org/listinfo/general
