SVN Revision-Like IDs in Git

Samuel Rodríguez samuelrp84 at gmail.com
Sat Aug 29 10:56:25 UTC 2020


> On Thu, Aug 13, 2020 at 3:10 PM Sideropoulos, Alexander <
> Alexander.Sideropoulos at netapp.com> wrote:
>
> > Thanks for the details, everyone. What I am gathering...
> >
> > 1) It is definitely possible for downstream projects (like NetApp) to
> > generate an SVN revision-like ID with a one-to-one mapping of Git
commits
> > on a single branch. Care must be taken to use the same flags every time
> > when "looking up" this number (e.g. to account for merge commits, etc.).
> >
> > 2) There are no plans for the FreeBSD project to provide generation
> > numbers across all branches nor within a single branch. There are some
> > plans for temporary SVN replication, though it is unclear for how long
this
> > will be provided and whether these will be available in the Git notes as
> > they are now.
> >
> > So at least for our use-case at NetApp, it seems we should just bite the
> > bullet and update our tooling to use Git commit hashes as input.
> >
> > But I cannot help but wonder... would it behoove FreeBSD to just provide
> > these generation numbers as a service to all downstream projects?
> >
>
> We're looking at ways to provide this for current branches (11, 12).
> There's a number of ways to do this, including continuing to publish this
> data via subversion. We've heard from others as well expressing concern
> around this part of the plan.
>
>
> > Setting up a post-commit hook which generates this number and updates
the
> > commit notes would solve this problem for everyone, including FreeBSD's
own
> > release process. More so, this process could easily ensure the numbers
are
> > unique (and time-ordered) across branches, even continuing the sequence
> > from the last SVN ID. Is that not desirable?
> >
>
> What other open source projects do this in the git world?

Haiku had gone through svn to git migration in 2011 and the approach the
project had taken was based on pushing tags named with a prefix and the svn
revision number taken from git-svn-id label provided by git svn migration
tool.

The prefix is hrev or btrev for the haiku and builtools repositories
respectively plus a extra text matching the branch name if applicable.

The result can be seen in the URLs below:

https://git.haiku-os.org/haiku/
https://git.haiku-os.org/buildtools/

Once the migration was effective, a post-receive git hook to handle the
creation of new tags based on commits pushed to the central repository
had been introduced. The creates incremental revision numbers with different
prefixes depending on branch names.

https://github.com/haiku/infrastructure/blob/master/data/gerrit/hooks/receive-notify.pl#L766

Other build system related scripts for versioning proposes are detailed
below:

https://git.haiku-os.org/haiku/tree/build/scripts/determine_haiku_revision
https://git.haiku-os.org/haiku/tree/build/jam/FileRules

Oliver Tappe gave a tech talk at BeGeistert 024 about the migration process:

https://www.youtube.com/watch?v=yPZDLNHf_70
https://www.youtube.com/watch?v=vxjZ--ne-zc
https://www.youtube.com/watch?v=_XQmZ6o0y38
https://www.youtube.com/watch?v=_mPEMOdBmBA

Hope it helps.

>
> Committing to this course of action commits to a global lock. Since git is
> distributed, you often have slight temporal distortions in the commit
> sequences. git makes no date ordering guarantees. Without a date order,
> having a serial number assigned per commit will also necessarily be out of
> date order. This will be especially interesting when multiple patches land
> all at once for things like security advisories that may have been done
> days or weeks in the past prior to their being pushed due to embargo
> reasons.
>
> I'm not forestalling this possibility, but anything we come up with will
be
> an imperfect FreeBSD-only solution.  Depending on how that's done, one
that
> we may have difficulty transporting to different 3rd parties and/or other
> services that we'd like to roll out in the future (or maybe not, without
> seeing any plan, it's hard to say one way or the other).
>
> Warner
>
>
> > --ap
> >
> > On 8/9/20, 14:29, "Ed Maste" <emaste at freebsd.org> wrote:
> >
> >     NetApp Security WARNING: This is an external email. Do not click
links
> > or open attachments unless you recognize the sender and know the
content is
> > safe.
> >
> >
> >
> >
> >     On Thu, 6 Aug 2020 at 21:27, Warner Losh <imp at bsdimp.com> wrote:
> >     >
> >     > On Thu, Aug 6, 2020, 4:01 PM Sideropoulos, Alexander <
> >     > Alexander.Sideropoulos at netapp.com> wrote:
> >     >
> >     > > Hey folks,
> >     > >
> >     > > According to this page...
> >     > >
> >     > >
> >
https://hackmd.io/_lvyl1CfTsayB3L0v4fmLA#What%E2%80%99s-with-the-funny-revision-hashes-I-want-revision-numbers
> >     > >
> >     > > ...there are no plans to provide an SVN-revision-like ID for Git
> > commits
> >     > > once the switch-over happens.
> >     > >
> >     > > At NetApp, we rely on the SVN revision number to uniquely
identify
> > our
> >     > > FreeBSD baseline and every cherry-picked patch we apply on top
of
> > it. We
> >     > > could update all our tooling to accept Git hashes, but this is
not
> > a small
> >     > > task. And I imagine we are not the only downstream project
reliant
> > upon SVN
> >     > > revision numbers.
> >     > >
> >     > > Since the SVN revision ID is really just an arbitrary number,
has
> > there
> >     > > been any thought in simply continuing to manufacture these
numbers
> > for Git
> >     > > commits going forward? It could even be a post-commit operation
> > where the
> >     > > Git notes are updated with a unique (increasing) ID, just as is
> > done today.
> >     > >
> >     > > Thoughts?
> >     > >
> >     >
> >     > Git has the ability to generate a number of commits since the last
> > tag (or
> >     > maybe arbitrary tag). That is appropriately the same thing if you
> > don't
> >     > need temporal stability between branches...
> >
> >     Git has a "generation number" that could be used for this purpose,
but
> >     unfortunately it isn't exposed in a user-facing way. It is possible
to
> >     count the number of commits from the root to the current head
though,
> >     and we include this number in the uname if build from git today. It
> >     appears as a "-cXXXXXX" suffix. As long as you are tracking or
> >     comparing only within a branch (e.g. stable/12) as Warner says it
can
> >     be used equivalently.
> >
> >     In sys/conf/newvers.sh have a look at the block following the "if [
-n
> >     "$git_cmd" ] ; then"
> >
> >

Thanks,
Samuel Rodríguez Pérez


More information about the freebsd-git mailing list