Difference between revisions of "git migration"

From Free Pascal wiki
(What part of SVN to migrate ?)
(More organised workflow section with pros and cons)
Line 12: Line 12:
  
 
== Branching model ?  ==
 
== Branching model ?  ==
Various models exist:
+
Various workflow models exist:
  [https://barro.github.io/2016/02/a-succesful-git-branching-model-considered-harmful/ Something like the current one]
+
* [http://nvie.com/posts/a-successful-git-branching-model/ A successful Git branching model] (also known as "git-flow").
  [http://nvie.com/posts/a-successful-git-branching-model/ or a different one?]
+
**'''Pros'''
 +
***A simple and logical workflow that plays to the strengths of Git - branching and merging.
 +
***'master', 'develop' and 'release' are good branch names which immediately makes it obvious what they are for. Many developers clone a repo and want or expect a stable version. This workflow allows just that - the 'master' branch is the default branch, and is always the latest stable release of the product.
 +
**'''Cons'''
 +
*** // to be written
 +
* [https://barro.github.io/2016/02/a-succesful-git-branching-model-considered-harmful/ The cactus model] or anti-"A successful Git branching Model".
 +
**'''Pros'''
 +
*** // to be written
 +
**'''Cons'''
 +
***Git was designed to work well with branches and handle merging as a common task. This workflow suggests merging as a bad idea, which is crazy.
 +
***This model recommends that a human must now keep track of which commits to cherry-pick into other branches. This is bounds to fail in the long run and vital commits will be missed at some point. Merging two or more branches on the contrary will automatically handle all commits in a branch seamlessly, so why not use what Git was designed to do well.
 +
***This model suggests that you can also cherry-pick from an unstable branch back into a stable release branch. This is just the wrong way round.
 +
***This model sees some of its own flaws and suggests a 3rd party tool to help keep track of things like cherry-picking. This simply isn't needed if you use a better workflow.
 +
* See the Git project itself.
 +
**'''Pros'''
 +
*** // to be written
 +
**'''Cons'''
 +
*** // to be written
 +
 
 
== User management ? ==
 
== User management ? ==
 
Git has no concept of users. To manage permissions on a server, a separate program is needed.
 
Git has no concept of users. To manage permissions on a server, a separate program is needed.

Revision as of 14:32, 17 December 2017

This page is about migrating FPC from SVN to git

Concerns/Questions

What part of SVN to migrate ?

  • More is better.
    Jonas has a very complete git mirror of the SVN+CVS part.
    (care needs to be taken: there used to be a time when copyrighted code was checked in)
    A first test conversion by Florian using subgit was attempted: completed in 5 hours 1, creash. Looks OK.
  • In order to save on diskspace, find ways to tell user how to clone only a part.

Use git clone --depth 1 to get only the latest revision (with fetch, later on more revisions can be fetched if needed)

Build repository

The fpc build repository uses svn:external references.

Git has modules, which is in essence the same. This needs to be properly set up.

Branching model ?

Various workflow models exist:

  • A successful Git branching model (also known as "git-flow").
    • Pros
      • A simple and logical workflow that plays to the strengths of Git - branching and merging.
      • 'master', 'develop' and 'release' are good branch names which immediately makes it obvious what they are for. Many developers clone a repo and want or expect a stable version. This workflow allows just that - the 'master' branch is the default branch, and is always the latest stable release of the product.
    • Cons
      • // to be written
  • The cactus model or anti-"A successful Git branching Model".
    • Pros
      • // to be written
    • Cons
      • Git was designed to work well with branches and handle merging as a common task. This workflow suggests merging as a bad idea, which is crazy.
      • This model recommends that a human must now keep track of which commits to cherry-pick into other branches. This is bounds to fail in the long run and vital commits will be missed at some point. Merging two or more branches on the contrary will automatically handle all commits in a branch seamlessly, so why not use what Git was designed to do well.
      • This model suggests that you can also cherry-pick from an unstable branch back into a stable release branch. This is just the wrong way round.
      • This model sees some of its own flaws and suggests a 3rd party tool to help keep track of things like cherry-picking. This simply isn't needed if you use a better workflow.
  • See the Git project itself.
    • Pros
      • // to be written
    • Cons
      • // to be written

User management ?

Git has no concept of users. To manage permissions on a server, a separate program is needed.

gitorious

  • Advantages
    • uses git repo for administration
    • No server binary
  • Disadvantages
    • No web interface
    • administration needs ssh key, only ssh possible.
    • Web integration ?

gitea

  • Advantages
    • Web based
    • Fine tuning possible
  • Disadvantages
    • Separate config
    • Requires running binary all the time, on a separate port.

What about Lazarus ?

Tool for migration

subgit

Advantages

  • very flexible
  • very fast (remote cloning of the whole FPC repository takes ?)

Disadvantages

  • external java-based tool, so some dependencies

git-svn

Advantages

  • included in git it self

Disadvantages

  • less flexible

Work to do

Migrate SVN repo.

  • 2017-12-16: A first test conversion by Florian using subgit was attempted: completed in 5 hours 1, creash. Looks OK

Set up user management and permissions.

Set up and automate github mirror