2009/10/18 Norbert Preining <preining@xxxxxxxx>: > On So, 18 Okt 2009, demerphq wrote: >> > Being a DVCS, this kind of versioning can only be trusted on a single repo, >> > but if you set it on the "main" repo, it should work. >> > >> > The only drawback could be the ever growing number of tags, >> > I don't know how it will work with thousands of tags or more. >> >> I think the other drawback is that the number would essentially be >> meaningless and more or less would just be a substitute sha1. > > Well, it would be increasing for that repository. And if we always > update our packages from that repository the packages will be guaranteed > to have increasing version number, too. > > That is the *only* thing I care about. The numbers don't need to have > a meaning, nothing else but that in our workflow we guarantee > that at the end each package progresses in version numbers. > >> Consider when a remote adds commits and then merges and pushes. What >> number should those commits have? > > When using a central repository to which he pushes within that central > repository it would give a specific number. Consider you have A-B-C-D-E in your master repo. So presumably numbered 1..5. If i then make a trivial comment fix to A and then merge and push we end up with: A-B-C-D-E-G \ / F------+ If i understand you right you will set F to 6 and G to 7. Thus youll end up with the problem that F is a descendent of A yet has a higher "version number" than E. You can repeat this process for ever. If this suits your needs then great. cheers, Yves -- perl -Mre=debug -e "/just|another|perl|hacker/" -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html