Difference between revisions of "FAQ SVN to GIT"

From Lazarus wiki
Jump to navigationJump to search
Line 48: Line 48:
 
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").

Revision as of 11:16, 1 August 2021

Where is the new GIT repro

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 to that one.

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
    • Easy switching between branches
    • Syncing between different machines (Laptop, Virtual machine) without needing a server. This helps tremendously with testing for different platforms.
    • Working offline
    • ... (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 on 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.