Difference between revisions of "FAQ SVN to GIT"

From Lazarus wiki
Jump to navigationJump to search
 
(4 intermediate revisions by 2 users not shown)
Line 1: Line 1:
= Where is the new GIT repro =  
+
== Where is the new GIT repo ==  
  
 
* https://gitlab.com/freepascal.org/fpc
 
* https://gitlab.com/freepascal.org/fpc
Line 11: Line 11:
 
(As long as Sourceforge supports it)
 
(As long as Sourceforge supports it)
  
 
+
== Where can I get help to use GIT ==
= Where can I get help to use GIT =
 
  
 
There are 2 pages to help moving from SVN to GIT.  
 
There are 2 pages to help moving from SVN to GIT.  
Line 20: Line 19:
 
* [[SVN_to_GIT_Cheatsheet]] (based on new "git switch")
 
* [[SVN_to_GIT_Cheatsheet]] (based on new "git switch")
  
and the official help:
+
* https://git-scm.com/docs (the official Git help)
* https://git-scm.com/docs
+
* [https://www.syncfusion.com/succinctly-free-ebooks/git GIT Succinctly] - Free Ebook (PDF, MOBI, EPUB) from SyncFusion.
 +
 
 +
=== How can I get the (checkout/download) sources from GIT ===
 +
 
 +
See the above pages.
 +
 
 +
Install a git client (command line) and run
 +
 
 +
    git clone  https://gitlab.com/freepascal.org/fpc/source.git  my_local_dir
 +
    git clone  https://gitlab.com/freepascal.org/lazarus/lazarus.git  my_local_dir
 +
 
 +
After that (to update)
 +
    git pull   
 +
 
 +
Then use (depending which guide you follow)
 +
    git checkout main
 +
    git checkout fixes-2_2
 +
    git switch main
 +
    git switch fixes-2_2
  
= Why did we move to GIT =
+
== Why did we move to GIT ==
  
 
There are many reasons. Some of them were:
 
There are many reasons. Some of them were:
Line 34: Line 51:
 
** '''Syncing between different machines''' (Laptop, Virtual machine) without needing an (external) server. This helps tremendously with testing for different platforms.
 
** '''Syncing between different machines''' (Laptop, Virtual machine) without needing an (external) server. This helps tremendously with testing for different platforms.
 
** Working offline
 
** Working offline
** Personal forks of the repro. For example to share a patch by publishing a branch (unfinished work / may still need to be completely redone) on your personal fork.
+
** Personal forks of the repo. For example to share a patch by publishing a branch (unfinished work / may still need to be completely redone) on your personal fork.
 
** ... (I need to go through old mails to find the remaining reasons)
 
** ... (I need to go through old mails to find the remaining reasons)
 
* Maintenance: Hosted solution (see "Why GitLab"). To the best of our knowledge there is no hosted SVN platform offering even half of what hosted GIT platform offer.<br/>This includes the high maintenance cost of running Mantis
 
* Maintenance: Hosted solution (see "Why GitLab"). To the best of our knowledge there is no hosted SVN platform offering even half of what hosted GIT platform offer.<br/>This includes the high maintenance cost of running Mantis
Line 42: Line 59:
 
On the long run, we may also be able to use the additional features offered by the hoster (that would have applied to GitHup or GitLab), such as CI integration. But that's to be seen in future.
 
On the long run, we may also be able to use the additional features offered by the hoster (that would have applied to GitHup or GitLab), such as CI integration. But that's to be seen in future.
  
== Why GitLab ==
+
=== Why GitLab ===
  
 
Self hosting becomes more and more involved. Aside from the technical maintenance needs, the legal requirements are getting bigger and bigger. In order to protect our self, and save time we decided to use a hosted platform.
 
Self hosting becomes more and more involved. Aside from the technical maintenance needs, the legal requirements are getting bigger and bigger. In order to protect our self, and save time we decided to use a hosted platform.
Line 49: Line 66:
 
* GitLab is open source. If ever we need to self host again, we have the choice to keep the platform.
 
* GitLab is open source. If ever we need to self host again, we have the choice to keep the platform.
  
 
+
=== Why now ===
== Why now ==
 
  
 
The old server would have had to be replaced now. So we were at a point where we had to invest considerable time and effort in any way we could go. Given that the move to Git had been decided, there was no point to invest time into temporarily extending SVN.
 
The old server would have had to be replaced now. So we were at a point where we had to invest considerable time and effort in any way we could go. Given that the move to Git had been decided, there was no point to invest time into temporarily extending SVN.
  
= What if I really can't switch to GIT =
+
== What if I really can't switch to GIT ==
  
 
We have mirrors at GitHub. And GitHub (currently) allows to access them with an svn client. (see the drop-down for the "clone url").
 
We have mirrors at GitHub. And GitHub (currently) allows to access them with an svn client. (see the drop-down for the "clone url").

Latest revision as of 23:27, 13 January 2022

Where is the new GIT repo

And a mirror (FPC and Lazarus) at

And for Lazarus

(As long as Sourceforge supports it)

Where can I get help to use GIT

There are 2 pages to help moving from SVN to GIT. Each page is a full "SVN to GIT" overview. The pages are alternatives to each other. You should choose one and stick with that one.

How can I get the (checkout/download) sources from GIT

See the above pages.

Install a git client (command line) and run

   git clone  https://gitlab.com/freepascal.org/fpc/source.git  my_local_dir
   git clone  https://gitlab.com/freepascal.org/lazarus/lazarus.git  my_local_dir

After that (to update)

   git pull    

Then use (depending which guide you follow)

   git checkout main
   git checkout fixes-2_2
   git switch main
   git switch fixes-2_2

Why did we move to GIT

There are many reasons. Some of them were:

  • For those who make commits to the project, GIT offers a lot of useful feature.
    That is: Perceived as useful by those who make the commits. And therefore helping the daily workflow of the team. (It doesn't matter, if those features are overall better or worse than SVN. They are better for those who work most with the repository)
    • Local branches, as quick temp storage (not svn shelves / that would be git stash)
      • This can be used as "savepoint" while working on a commit. (Saving a partial commit, in case one needs to roll back)
      • Storing an unfinished attempt on some idea
    • Easy switching between branches
    • Syncing between different machines (Laptop, Virtual machine) without needing an (external) server. This helps tremendously with testing for different platforms.
    • Working offline
    • Personal forks of the repo. For example to share a patch by publishing a branch (unfinished work / may still need to be completely redone) on your personal fork.
    • ... (I need to go through old mails to find the remaining reasons)
  • Maintenance: Hosted solution (see "Why GitLab"). To the best of our knowledge there is no hosted SVN platform offering even half of what hosted GIT platform offer.
    This includes the high maintenance cost of running Mantis

Note that several team members have in the past already used "git svn" and similar solutions. Despite the downsides (e.g. git svn, is really slow to update), this means that the above points are not just hopeful assumptions. The listed "perceived git advantages" have already been experienced by those team members.

On the long run, we may also be able to use the additional features offered by the hoster (that would have applied to GitHup or GitLab), such as CI integration. But that's to be seen in future.

Why GitLab

Self hosting becomes more and more involved. Aside from the technical maintenance needs, the legal requirements are getting bigger and bigger. In order to protect our self, and save time we decided to use a hosted platform.

  • GitLab offers a very good deal to open source projects. Better than GitHub, at this time.
  • GitLab is open source. If ever we need to self host again, we have the choice to keep the platform.

Why now

The old server would have had to be replaced now. So we were at a point where we had to invest considerable time and effort in any way we could go. Given that the move to Git had been decided, there was no point to invest time into temporarily extending SVN.

What if I really can't switch to GIT

We have mirrors at GitHub. And GitHub (currently) allows to access them with an svn client. (see the drop-down for the "clone url").

However, this should be only used as a last resort. The teams do not have any plans to invest time into supporting this. It is there as long as GitHub offers it for free.

Further, it is incompatible with the old svn. GitHub reverse translates it from git. So each revision gets a new arbitrary revision number. And those numbers can not be used to report/discuss issues. No one in the team uses this svn-mirror, so non of us has access to those revision numbers. To report issues you need the git sha1.