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 that none 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 of it 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...
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 that none 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 of it 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.
--
Magnus Hagander
Me: 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 that none 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 of it 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 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.
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 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...
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 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 :-(
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 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 :-(
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