[postgis-devel] Duplicate tags appearing in postgis git repo

[John Harvey]

Hi strk,

I'm afraid SVN doesn't have a way to publish immutable tags, so
> if a "tag branch" was committed into after-the-fact, we'd have no
> way to know when the tag was made. Am I right in that reguard ?
>

If I remember right (it's been a few years), on a past project in SVN, we
handled it this way:
There were separate "tags" and "branches" areas, and then when it was time
to tag, we copied the branch via "svn cp" into the "tags" area and then I
think we locked that tag.  This way, the branch could go forward and the
tag could not be touched.

The current postgis project appears to use a model branches and tags, but
it appears that the tags are not locked.
Therefore, it is conceivable that tags can move forward in time.


> The init script reconstructs the mirror from a git repository, but the
> original git repository is now lost due to force-pushing new tag
> values.  Some local ones may still exist, as yours and mine somewhere.
> Do we really want to reconstruct those tags from our local values of
> tags ? Note that only recently I added a -f to the `git tag` call in
> that syncer, so it could very well be that the previous tag just
> pointed to whatever state the SVN "tag/branch" had at time of
> mirroring...
>

>From what I see, the "old" tags in git seem to correspond to the time where
the release tarballs were made both based on date and also by inspection of
commit messages (below are the commit messages):

   - 2.2.0: - Tagged release 2.2.0
   - 2.2.0_rc1 - Set version numbers
   - 2.1.7 - Tagged release 2.1.7
   - 2.1.6 - Tagged release 2.1.6
   - 2.1.3 - Set final version to 2.1.3
   - 2.1.0beta1 - repoint to OSGEO download section
   - 2.0.3 - Release 2.0.3 tagged

I don't think the old tag placement was from an arbitrary point in time--
for these 7 items, it appears that they line up with when the release of
the time that the source tarballs were created and released.

The thing that is bothering me about this is that with the tags moved, the
project has sacrificed build reproducibility.  I can see that contributors
can add (and have added) content to a subversion tag long after a release
occurred.  When this happened, it made it so that a build made from source
on that tag (in both subversion and in git) no longer matches the release
tarball's content.  That is what worries me.

Let's look at a singular example: 2.2.0.

   1. The tagged release happened  on 10/7/2015.
   2. The release was announced:
   http://postgis.net/2015/10/07/postgis-2.2.0/
   3. The corresponding source tarball was posted:
   http://download.osgeo.org/postgis/source/postgis-2.2.0.tar.gz
   4. 4 months after release, 7 code commits were added to this tag.  At
   this point, the subversion tag does not match the released tarball.
   5. A few days ago, the git tag was moved on top of these 7 commits.  At
   this point, the git tag does not the released tarball.

The correct placement of this tag needs to be he 10/7/2015 commit, where
the source tarball was generated.  I'm failing to think of any room for any
other answer here-- reproducibility to match that release tarball should be
a must-have with any version control system.

>From what I can see, there are two ways to fix things:

   1. Delete the erroneous commits on top of the tags.  This will let the
   automated tag-pusher work correctly.  This also has the benefit of fixing
   subversion from being mismatched from previously released source tarballs.
   Although, people may not want to do this.
   2. Move the specifically noted tags from my previous message back to
   their original positions.  This fixes git (and may be easy to do), but does
   not fix subversion.

I'm not really too invested in which path is chosen to fix it, but I do
think it's a large CM problem if the release tarballs don't line up with
the built source tags.  Others can share their perspective as well; I'm a
build/release engineer by trade, so I must admit that I may have some bias
in this area.

Thanks!
  -John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20170519/2f3d7286/attachment.html>