Thread: Tags missing from GIT mirror?
Hi I just tried to checkout REL9_0_BETA1 from my local clone of the GIT repository at git.postgresql.org and discovered thatnone of the tags from CVS seem to exist in there. For alpha1 to alpha1 each tag is accompanied by a corresponding brach,and those *do* exist on the GIT mirror. For beta1, however, no branch seems to exist, and hence there is no trace ofit on the GIT mirror. Why is there a branch plus a tag for alphas, but only a tag for betas? I'd have assumed that both would just be tags, butobviously I'm missing something there... best regards, Florian Pflug
On Wed, May 12, 2010 at 8:27 PM, Florian Pflug <fgp@phlo.org> wrote: > Hi > > I just tried to checkout REL9_0_BETA1 from my local clone of the GIT repository at git.postgresql.org and discovered thatnone of the tags from CVS seem to exist in there. For alpha1 to alpha1 each tag is accompanied by a corresponding brach,and those *do* exist on the GIT mirror. For beta1, however, no branch seems to exist, and hence there is no trace ofit on the GIT mirror. > > Why is there a branch plus a tag for alphas, but only a tag for betas? I'd have assumed that both would just be tags, butobviously I'm missing something there... I think we branched the alphas so we could version-stamp them while keeping HEAD as "9.0devel". But when we switch to beta, we don't have a devel tree anymore, it's just beta and backbranches. -- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/
On May 12, 2010, at 1:43 PM, Magnus Hagander wrote: > On Wed, May 12, 2010 at 8:27 PM, Florian Pflug <fgp@phlo.org> wrote: >> Hi >> >> I just tried to checkout REL9_0_BETA1 from my local clone of the GIT repository at git.postgresql.org and discovered thatnone of the tags from CVS seem to exist in there. For alpha1 to alpha1 each tag is accompanied by a corresponding brach,and those *do* exist on the GIT mirror. For beta1, however, no branch seems to exist, and hence there is no trace ofit on the GIT mirror. >> >> Why is there a branch plus a tag for alphas, but only a tag for betas? I'd have assumed that both would just be tags,but obviously I'm missing something there... > > I think we branched the alphas so we could version-stamp them while > keeping HEAD as "9.0devel". But when we switch to beta, we don't have > a devel tree anymore, it's just beta and backbranches. Is there anything to do about the missing tags in git? I've wished for those to be available as well. Regards, David -- David Christensen End Point Corporation david@endpoint.com
David Christensen wrote: > > Is there anything to do about the missing tags in git? I've wished for those to be available as well. > > > Sure, fix fromcvs to emit them. How is your ruby? cheers andrew
On May 12, 2010, at 21:52 , Andrew Dunstan wrote: > David Christensen wrote: >> >> Is there anything to do about the missing tags in git? I've wished for those to be available as well. >> > > Sure, fix fromcvs to emit them. How is your ruby? Where does one find the version of fromcvs used to feed git.postgresql.org? I might give it a shot. I can't promise anything, though - my ruby-fu is OK, but my cvs-fu is badly lacking... best regards, Florian Pflug
Andrew Dunstan <andrew@dunslane.net> writes:
> David Christensen wrote:
>> Is there anything to do about the missing tags in git? I've wished for those to be available as well.
> Sure, fix fromcvs to emit them. How is your ruby?
Per Magnus' comment, there isn't anything "missing". We don't make
branches for beta releases. (Personally I'm thinking that having stub
branches for the alphas was a mistake too --- obviously, it's leading to
confusion.)
regards, tom lane
Florian Pflug wrote: > On May 12, 2010, at 21:52 , Andrew Dunstan wrote: > >> David Christensen wrote: >> >>> Is there anything to do about the missing tags in git? I've wished for those to be available as well. >>> >>> >> Sure, fix fromcvs to emit them. How is your ruby? >> > > > Where does one find the version of fromcvs used to feed git.postgresql.org? I might give it a shot. > > I can't promise anything, though - my ruby-fu is OK, but my cvs-fu is badly lacking... > > > Fix the tip version. You'll need fromcvs and rcsparse from <http://ww2.fs.ei.tum.de/~corecode/hg>. We already know that the version used on the community repo is broken. The version I am using on my github mirror is holding up OK. There is a recipe for setting up a mirror on my blog: <http://people.planetpostgresql.org/andrew/index.php?/archives/74-Gory-details.html>. Of course, we might also find some other brokenness if we try to import all the tags. Also, be aware of this (from <http://cvs2svn.tigris.org/cvs2git.html>): Differences between CVS and git branch/tag models: CVS allows a branch or tag to be created from arbitrary combinationsof source revisions from multiple source branches. It even allows file revisions that were never contemporaneousto be added to a single branch/tag. Git, on the other hand, only allows the full source tree, as it existedat some instant in the history, to be branched or tagged as a unit. Moreover, the ancestry of a git revision makes implications about the contents of that revision. This difference means that it is fundamentally impossible to representan arbitrary CVS history in a git repository 100% faithfully. cheers andrew
On May 12, 2010, at 22:03 , Tom Lane wrote: > Andrew Dunstan <andrew@dunslane.net> writes: >> David Christensen wrote: >>> Is there anything to do about the missing tags in git? I've wished for those to be available as well. > >> Sure, fix fromcvs to emit them. How is your ruby? > > Per Magnus' comment, there isn't anything "missing". We don't make > branches for beta releases. (Personally I'm thinking that having stub > branches for the alphas was a mistake too --- obviously, it's leading to > confusion.) Yeah, but CVS has tags for the alphas and betas. Those are missing from the GIT mirror as the CVS-to-GIT converter apparentlyignores tags completely :-(. Since there are no branches for the betas, this leaves the GIT repository withoutany trace that beta1 exists at all... So there is nothing wrong with the CVS, but on the GIT side there is certainly room for improvement. best regards, Florian Pflug
Florian Pflug <fgp@phlo.org> writes:
> Yeah, but CVS has tags for the alphas and betas. Those are missing from the GIT mirror as the CVS-to-GIT converter
apparentlyignores tags completely :-(. Since there are no branches for the betas, this leaves the GIT repository
withoutany trace that beta1 exists at all...
Really? Then it wouldn't know about any past point-releases either :-(
regards, tom lane
Tom Lane wrote: > Andrew Dunstan <andrew@dunslane.net> writes: > >> David Christensen wrote: >> >>> Is there anything to do about the missing tags in git? I've wished for those to be available as well. >>> > > >> Sure, fix fromcvs to emit them. How is your ruby? >> > > Per Magnus' comment, there isn't anything "missing". We don't make > branches for beta releases. (Personally I'm thinking that having stub > branches for the alphas was a mistake too --- obviously, it's leading to > confusion.) > > > What's missing is a non branch tag. It's there in CVS and not in the git repos. cheers andrew
Tom Lane wrote: > Florian Pflug <fgp@phlo.org> writes: > >> Yeah, but CVS has tags for the alphas and betas. Those are missing from the GIT mirror as the CVS-to-GIT converter apparentlyignores tags completely :-(. Since there are no branches for the betas, this leaves the GIT repository withoutany trace that beta1 exists at all... >> > > Really? Then it wouldn't know about any past point-releases either :-( > > > Presumably when we cut over to git properly, we will use some other tool that does import non-branch tags. But for now fromcvs is effectively the only game in town for incremental mirroring. Of course, if someone fixed it to handle tags that would be cool ... cheers andrew
On 12.05.2010, at 22:22, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Florian Pflug <fgp@phlo.org> writes: >> Yeah, but CVS has tags for the alphas and betas. Those are missing >> from the GIT mirror as the CVS-to-GIT converter apparently ignores >> tags completely :-(. Since there are no branches for the betas, >> this leaves the GIT repository without any trace that beta1 exists >> at all... > > Really? Then it wouldn't know about any past point-releases > either :-( It doesn't :-( Best regards Florian Pflug
On ons, 2010-05-12 at 16:11 -0400, Andrew Dunstan wrote: > Of course, we might also find some other brokenness if we try to import > all the tags. Also, be aware of this (from > <http://cvs2svn.tigris.org/cvs2git.html>): > > Differences between CVS and git branch/tag models: CVS allows a > branch or tag to be created from arbitrary combinations of source > revisions from multiple source branches. It even allows file > revisions that were never contemporaneous to be added to a single > branch/tag. Git, on the other hand, only allows the full source > tree, as it existed at some instant in the history, to be branched > or tagged as a unit. Moreover, the ancestry of a git revision makes > implications about the contents of that revision. This difference > means that it is fundamentally impossible to represent an arbitrary > CVS history in a git repository 100% faithfully. Right, and omitting tags was in fact one of the "features" of fromcvs that made us use it, because any tool that tries to convert tags will explode on our CVS tree, for reasons explained in the above paragraph. We have also discussed this in more detail about three times before.
Peter Eisentraut wrote: > On ons, 2010-05-12 at 16:11 -0400, Andrew Dunstan wrote: > >> Of course, we might also find some other brokenness if we try to import >> all the tags. Also, be aware of this (from >> <http://cvs2svn.tigris.org/cvs2git.html>): >> >> Differences between CVS and git branch/tag models: CVS allows a >> branch or tag to be created from arbitrary combinations of source >> revisions from multiple source branches. It even allows file >> revisions that were never contemporaneous to be added to a single >> branch/tag. Git, on the other hand, only allows the full source >> tree, as it existed at some instant in the history, to be branched >> or tagged as a unit. Moreover, the ancestry of a git revision makes >> implications about the contents of that revision. This difference >> means that it is fundamentally impossible to represent an arbitrary >> CVS history in a git repository 100% faithfully. >> > > Right, and omitting tags was in fact one of the "features" of fromcvs > that made us use it, because any tool that tries to convert tags will > explode on our CVS tree, for reasons explained in the above paragraph. > > We have also discussed this in more detail about three times before. > > Well, yes, but I have been wondering if this has to be an all or nothing deal. How many tags can we not tie to a known tree in git? My suspicion is we can probably identify most of them quite well. If we can that would be nice. cheers andrew
On tor, 2010-05-13 at 04:41 -0400, Andrew Dunstan wrote: > > Right, and omitting tags was in fact one of the "features" of fromcvs > > that made us use it, because any tool that tries to convert tags will > > explode on our CVS tree, for reasons explained in the above paragraph. > > > > We have also discussed this in more detail about three times before. > > Well, yes, but I have been wondering if this has to be an all or nothing > deal. How many tags can we not tie to a known tree in git? My suspicion > is we can probably identify most of them quite well. If we can that > would be nice. http://archives.postgresql.org/pgsql-hackers/2008-04/msg00036.php
Peter Eisentraut wrote: > On tor, 2010-05-13 at 04:41 -0400, Andrew Dunstan wrote: > >>> Right, and omitting tags was in fact one of the "features" of fromcvs >>> that made us use it, because any tool that tries to convert tags will >>> explode on our CVS tree, for reasons explained in the above paragraph. >>> >>> We have also discussed this in more detail about three times before. >>> >> Well, yes, but I have been wondering if this has to be an all or nothing >> deal. How many tags can we not tie to a known tree in git? My suspicion >> is we can probably identify most of them quite well. If we can that >> would be nice. >> > > http://archives.postgresql.org/pgsql-hackers/2008-04/msg00036.php > > Quite so. All the tags apparently causing problems are of no more than historical interest to us. But more recent tags, especially for currently maintained branches, are of interest. cheers andrew