Recent

Author Topic: FPC & Lazarus moving to gitlab  (Read 100154 times)

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9791
  • Debugger - SynEdit - and more
    • wiki
Re: FPC & Lazarus moving to gitlab
« Reply #45 on: June 24, 2021, 06:43:46 pm »
Some guide will be needed for smoother crossing from Mantis - explaining several best practice use cases with common category/label mapping. Otherwise everyone will have his own idea on how to achieve that...
We are in the process, of importing *all* existing issues. During that process each team will decide what labels to use.

avra

  • Hero Member
  • *****
  • Posts: 2514
    • Additional info
Re: FPC & Lazarus moving to gitlab
« Reply #46 on: June 25, 2021, 01:26:48 am »
Some guide will be needed for smoother crossing from Mantis - explaining several best practice use cases with common category/label mapping. Otherwise everyone will have his own idea on how to achieve that...
We are in the process, of importing *all* existing issues. During that process each team will decide what labels to use.
Thanks for that info. I have 2 new packages to add to FPC (can and bithelpers). Would it be better to provide patches now to Mantis or wait a little and do it in GitLab issues? I do not want to wait too much and miss FPC 3.4.0...
ct2laz - Conversion between Lazarus and CodeTyphon
bithelpers - Bit manipulation for standard types
pasettimino - Siemens S7 PLC lib

edwinyzh

  • New Member
  • *
  • Posts: 43
Re: FPC & Lazarus moving to gitlab
« Reply #47 on: June 25, 2021, 06:30:52 am »
I wonder what was the motivation for choosing gitlab over github? Self hosting possibility? Non M$? Code open sourced and available? Free storage size? Other?

Some guide will be needed for smoother crossing from Mantis - explaining several best practice use cases with common category/label mapping. Otherwise everyone will have his own idea on how to achieve that...
I have the same curiosity. But using git is definitely a great improvement!

PascalDragon

  • Hero Member
  • *****
  • Posts: 5446
  • Compiler Developer
Re: FPC & Lazarus moving to gitlab
« Reply #48 on: June 25, 2021, 09:04:18 am »
Quote
But, since the "svn advantage is gone", that can be done in GIT too. I can display the filtered log. I can
see the list, and pick the middle.

All my scripts (mostly FPC TProcess based) and every other infrastructure is invalidated. Worse, git seems to want bash for nearly everything which makes scripting a pain on Windows, specially when multiple driveletters are involved.

I have not once used bash on Windows to work with Git. Keep in mind that the Windows devs themselves are using Git nowadays (and before WSL!), so they're interested in a transparent integration as well.

I'm reluctant to do this all again, in case the gitlab thing doesn't work out in a few years, and we go back to hosted.

We'd probably roll our own instance of GitLab then. But the local commands wouldn't differ if the remote site is GitLab, GitHub or some plain Git repository.

< SARCASM MODE ON > :-[ :-[ :-[
If I remember well, many have complained that much more developers would contribute if GIT was the main version control system. Can't wait for that to happen...
< SARCASM MODE OFF > ;)  ;)  ;)

Yeah... that's a point I don't really believe in either. After all even if users should decide to provide pull/merge requests instead of merely patches we would still make sure that they are up to our standards which includes coding style and which will then even include how nicely done their commit history is (which there isn't with patches), so that there are no commits like "forgot to commit file x" or "fixed compilation".

I wonder what was the motivation for choosing gitlab over github? Self hosting possibility? Non M$? Code open sourced and available? Free storage size? Other?

Both "self hosting possibility" and "code open sourced and available".

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: FPC & Lazarus moving to gitlab
« Reply #49 on: June 25, 2021, 09:55:05 am »
We'd probably roll our own instance of GitLab then. But the local commands wouldn't differ if the remote site is GitLab, GitHub or some plain Git repository.

Which I suppose raises the interesting question of whether anybody has already implemented a shim which implements Subversion checkout behaviour on top of Git.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

ccrause

  • Hero Member
  • *****
  • Posts: 845
Re: FPC & Lazarus moving to gitlab
« Reply #50 on: June 25, 2021, 12:07:07 pm »
We'd probably roll our own instance of GitLab then. But the local commands wouldn't differ if the remote site is GitLab, GitHub or some plain Git repository.

Which I suppose raises the interesting question of whether anybody has already implemented a shim which implements Subversion checkout behaviour on top of Git.

MarkMLl
The opposite (git support for svn) does exist, but isn't helpful in this context... I suspect the problem is mapping from more complex to less complex functionality.  There is a kind of cheat sheet in the wiki that maps some common SVN operations to git equivalents.  Not the same as remapped commands, but a good cross-over guide.

DonAlfredo

  • Hero Member
  • *****
  • Posts: 1739
Re: FPC & Lazarus moving to gitlab
« Reply #51 on: June 25, 2021, 12:11:54 pm »
Fpcupdeluxe extracts the SVN repo number from GIT, if it is stored.
Code: https://github.com/LongDirtyAnimAlf/fpcupdeluxe/blob/master/gitclient.pas#L563

PascalDragon

  • Hero Member
  • *****
  • Posts: 5446
  • Compiler Developer
Re: FPC & Lazarus moving to gitlab
« Reply #52 on: June 25, 2021, 01:06:48 pm »
We'd probably roll our own instance of GitLab then. But the local commands wouldn't differ if the remote site is GitLab, GitHub or some plain Git repository.

Which I suppose raises the interesting question of whether anybody has already implemented a shim which implements Subversion checkout behaviour on top of Git.

GitHub provides the ability to check out with SVN. So once we have a GitHub mirror of the GitLab repository that can be used.

Fpcupdeluxe extracts the SVN repo number from GIT, if it is stored.
Code: https://github.com/LongDirtyAnimAlf/fpcupdeluxe/blob/master/gitclient.pas#L563

There won't be any SVN revisions with the translated repositories and even if there were there won't be any new ones after the date of the switch.

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: FPC & Lazarus moving to gitlab
« Reply #53 on: June 25, 2021, 01:20:37 pm »
GitHub provides the ability to check out with SVN. So once we have a GitHub mirror of the GitLab repository that can be used.

I might like the sound of that. Will that mean that going via Github there will still be something that approximates the current sequential release numbers?

As I've said, my beef is /entirely/ with the necessity of trunk users being pushed onto a new toolset.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

DonAlfredo

  • Hero Member
  • *****
  • Posts: 1739
Re: FPC & Lazarus moving to gitlab
« Reply #54 on: June 25, 2021, 01:33:21 pm »
Quote
There won't be any SVN revisions with the translated repositories and even if there were there won't be any new ones after the date of the switch.
For sure. But it might perhaps be good to consider a GIT commit hook script to magically create a kind of revision number or sequence that is a bit more human readable than the normal GIT hashes. And can be used as a reference.

avra

  • Hero Member
  • *****
  • Posts: 2514
    • Additional info
Re: FPC & Lazarus moving to gitlab
« Reply #55 on: June 25, 2021, 01:58:21 pm »
consider a GIT commit hook script to magically create a kind of revision number or sequence that is a bit more human readable than the normal GIT hashes. And can be used as a reference.
+1
ct2laz - Conversion between Lazarus and CodeTyphon
bithelpers - Bit manipulation for standard types
pasettimino - Siemens S7 PLC lib

dbannon

  • Hero Member
  • *****
  • Posts: 2786
    • tomboy-ng, a rewrite of the classic Tomboy
Re: FPC & Lazarus moving to gitlab
« Reply #56 on: June 25, 2021, 02:34:30 pm »
https://stackoverflow.com/questions/28792784/why-does-git-use-a-cryptographic-hash-function

The hash is a hash of the data in the repo at that point in time.  Its done to be a) unique and b) to guarantee the data.  SVN's sequential number does a) but tells us nothing about the data. On the other hand, git, while good at b)  cannot quite guarantee a).    :D

Personally, I have never taken a hash of my version to compare to a remote version of any git repo but I suppose someone does !

You could, I guess, have a layer that maps a sequential 'r' number to its hash. But you would need to rewrite, perhaps, half the git commands to do so.

I am a big fan of git but agree the svn 'r' number is heaps easier to use. (In most cases, you only use the first 6 to 8 digits of the hash).

Davo

 
Lazarus 3, Linux (and reluctantly Win10/11, OSX Monterey)
My Project - https://github.com/tomboy-notes/tomboy-ng and my github - https://github.com/davidbannon

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: FPC & Lazarus moving to gitlab
« Reply #57 on: June 25, 2021, 04:10:13 pm »
The hash is a hash of the data in the repo at that point in time.  Its done to be a) unique and b) to guarantee the data.  SVN's sequential number does a) but tells us nothing about the data. On the other hand, git, while good at b)  cannot quite guarantee a).    :D

You could almost say that there are three numbering requirements:

a) Uniqueness guarantee

b) Integrity guarantee

c) Sequential ordering guarantee

I don't know whether the identifier that is yielded as a result of (c) really has to be a pure number, as long as it can be parsed as being sequential: while I routinely incorporate Subversion revision numbers into build identifiers I'm used to having e.g. 12345M and would be surprised if anybody tried manipulating them under scripted or program control.

Having said which and bearing in mind a suggestion (admission?) that somebody made in a PM, one possibility would be if an Svn-revision-surrogate actually showed a Git hash plus the number of subsequent commits... it might not be completely robust under all possible scenarios but it would allow a subteam investigating e.g. a trunk regression to say "we're at #1a2b3c4d.56, but if we revert 10 commits to #1a2b3c4d.46 the problem doesn't occur".

In some ways that mirrors some of the comments I've made in the past relating to conferencing systems, where it's enormously easier to thread and xref messages if message identifiers are guaranteed consistent from the POV of all users: SMF (i.e. like this forum) complies with that, Usenet doesn't unless it can be guaranteed that all messages are stored on a single locally-accessible server. Also some of https://en.wikipedia.org/wiki/Tumbler_(Project_Xanadu) might be relevant.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

DonAlfredo

  • Hero Member
  • *****
  • Posts: 1739
Re: FPC & Lazarus moving to gitlab
« Reply #58 on: June 25, 2021, 04:27:34 pm »
Example of post-commit (far from perfect):
Code: Pascal  [Select][+][-]
  1. #!/bin/bash
  2.  
  3. REVFILE='fpcgitrevision.txt'
  4.  
  5. exec 1>&2
  6. branch=`git rev-parse --abbrev-ref HEAD`
  7. shorthash=`git log --pretty=format:'%h' -n 1`
  8. revcount=`git rev-list HEAD --count`
  9. latesttag=`git describe --tags --abbrev=0  --always`
  10.  
  11. VERSION="$branch-$latesttag-$revcount-hash[$shorthash]"
  12. echo $VERSION > $REVFILE
  13.  

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9791
  • Debugger - SynEdit - and more
    • wiki
Re: FPC & Lazarus moving to gitlab
« Reply #59 on: June 25, 2021, 05:30:32 pm »
There is a kind of cheat sheet in the wiki that maps some common SVN operations to git equivalents.
Actually in the spirit of GIT (more than one way for anything that may be done...), there are two: https://wiki.lazarus.freepascal.org/SVN_to_GIT_Cheatsheet

 

TinyPortal © 2005-2018