Difference between revisions of "git migration"

From Free Pascal wiki
Jump to navigationJump to search
Line 12: Line 12:
  
 
== Branching model ?  ==
 
== Branching model ?  ==
 +
 +
=== How to handle the fixes branch ===
 +
 
Various workflow models exist:
 
Various workflow models exist:
 +
 
===[http://nvie.com/posts/a-successful-git-branching-model/ A successful Git branching model]===
 
===[http://nvie.com/posts/a-successful-git-branching-model/ A successful Git branching model]===
 
Also known as "git-flow" model.
 
Also known as "git-flow" model.
Line 71: Line 75:
 
There seem to be dependencies on quite a few tools common on Unix platforms. Unfortunately, ports of these tools may not be up-to-date and/or working well on non-Unix platforms. As an example, port of GIT 2.13.3 to OS/2 lists dependencies on a Unix shell, Python, Perl and CURL among others. Using Unix shell for launching other programs on a non-Unix platform may have various unwanted effects (remember cygwin ports which we tried to avoid on MS Windows as much as possible for similar reasons). The list of dependencies seems to suggest that quite a few operations require external tools (similarly to merging with early SVN versions). It may be difficult to test all such cases potentially important for certain workflows in advance before the final switch.
 
There seem to be dependencies on quite a few tools common on Unix platforms. Unfortunately, ports of these tools may not be up-to-date and/or working well on non-Unix platforms. As an example, port of GIT 2.13.3 to OS/2 lists dependencies on a Unix shell, Python, Perl and CURL among others. Using Unix shell for launching other programs on a non-Unix platform may have various unwanted effects (remember cygwin ports which we tried to avoid on MS Windows as much as possible for similar reasons). The list of dependencies seems to suggest that quite a few operations require external tools (similarly to merging with early SVN versions). It may be difficult to test all such cases potentially important for certain workflows in advance before the final switch.
 
::OS/2 being the first commercial operating system to ship with Java built-in. So why not simply use the Java version of Git. The Eclipse and IntelliJ IDEA project do on a daily basis. --[[User:Ggeldenhuys|Graeme]] ([[User talk:Ggeldenhuys|talk]]) 14:39, 18 December 2017 (CET)
 
::OS/2 being the first commercial operating system to ship with Java built-in. So why not simply use the Java version of Git. The Eclipse and IntelliJ IDEA project do on a daily basis. --[[User:Ggeldenhuys|Graeme]] ([[User talk:Ggeldenhuys|talk]]) 14:39, 18 December 2017 (CET)
 +
 +
== Misc. ==
 +
 +
Collected from a mail of Marco which is not handled in other sections:
 +
 +
* I really dislike losing global revs.
 +
* Will we need to store anything in one repo (build and fpc?) Would be huge with all histo, and problematic for release building VMs etc . What are the options for partial checkouts/externals ?
 +
* Can branches be in a not usable (multi-head) state? I heard some complaints about that, where users avoided work till it was fixed, and had flashbacks of locking VCSes all over again. Should not be possible.
 +
* git requiring sequences of commands for simple operations (local than global push etc)
 +
* lineendings, should be entirely server dictated.
  
 
= Tool for migration =
 
= Tool for migration =

Revision as of 19:32, 18 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 ?

How to handle the fixes branch

Various workflow models exist:

A successful Git branching model

Also known as "git-flow" model.

  • Advantages
    • 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.
    • Features or multi-commit (complex) bug fixes show a clear commit history or related commits, that is easily tracked, viewed or even rolled-back in the commit history using a tool like gitk.
  • Disadvantages
    • It works only well if the the whole release policy of FPC is changed. This is something very likely not going to happen.
    • cluttered and basically unreadable history
    • doubled regression testing effort during development of new stuff
      • test branch before merge
      • test branch after merge, as merging could have broken things
    • micro management of branches: every single bug fixes requires and results in a new branch This is simply not the case. single bug fixes can be committed into the 'develop' branch as a linear history. Only more complex (multi-commit) fixes or features will result in a parallel history or development, but quickly merged back into 'develop'. --Graeme (talk) 18:50, 17 December 2017 (CET)
You do not see the problem: if it is in develop, it will never make it into master without merging whole develop into master (i.e. in terms of FPC releases this would mean a new minor release x.y+1.0). So each bug fix has to go into an own hotfixes branch (e.g. hotfix_bug12345) which is branched from master and merged first into develop. If it works, it will be merged back into master. --FPK (talk) 22:58, 17 December 2017 (CET)
    • One has to know before pushing how invasive a change is because it has to go in the right branch. For compiler development this is very cumbersome.

The cactus model

Also known as the anti-"A successful Git branching Model".

  • Advantages
    • clear and straight history
    • no time consuming micro management of branches
    • history and logs not cluttered with merge commits
    • no breakage by wrong conflict resolving during merge commits by less experienced users
  • Disadvantages
    • 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.
    • It suggests that 'rebase' get used often. This has always been frowned upon in the Git community, and it is widely known to use rebase sparingly as it rewrites history and doesn't result in a logical evolution of the code history.
    • This worklfow suggests that a merge commit is a bad thing. A merge commit is a commit like any other. It can be a simple commit (with no conflicts), or can be a commit that resolves conflicts (thus code changes were required - which this commit records). Nothing bad about that.

See the Git project itself

  • Advantages
    • The git project itself gets an extreme amount of contributions via pull requests and emailed patches. Their workflow model clearly works well and uses branching and merging extensively - even though the commit history looks quite scary. :-)
  • Disadvantages
    • // 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 ?

Dependencies on Unix-world tools / ports ?

There seem to be dependencies on quite a few tools common on Unix platforms. Unfortunately, ports of these tools may not be up-to-date and/or working well on non-Unix platforms. As an example, port of GIT 2.13.3 to OS/2 lists dependencies on a Unix shell, Python, Perl and CURL among others. Using Unix shell for launching other programs on a non-Unix platform may have various unwanted effects (remember cygwin ports which we tried to avoid on MS Windows as much as possible for similar reasons). The list of dependencies seems to suggest that quite a few operations require external tools (similarly to merging with early SVN versions). It may be difficult to test all such cases potentially important for certain workflows in advance before the final switch.

OS/2 being the first commercial operating system to ship with Java built-in. So why not simply use the Java version of Git. The Eclipse and IntelliJ IDEA project do on a daily basis. --Graeme (talk) 14:39, 18 December 2017 (CET)

Misc.

Collected from a mail of Marco which is not handled in other sections:

  • I really dislike losing global revs.
  • Will we need to store anything in one repo (build and fpc?) Would be huge with all histo, and problematic for release building VMs etc . What are the options for partial checkouts/externals ?
  • Can branches be in a not usable (multi-head) state? I heard some complaints about that, where users avoided work till it was fixed, and had flashbacks of locking VCSes all over again. Should not be possible.
  • git requiring sequences of commands for simple operations (local than global push etc)
  • lineendings, should be entirely server dictated.

Tool for migration

subgit

Advantages

  • very flexible
  • very fast (remote cloning of the whole FPC repository takes 5-6 hours)

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 crash. Looks OK

Branch mapping for subgit

Proposal for branch mapping

excludeBranches = branches/aspect
excludeBranches = branches/avr32
excludeBranches = branches/blaise
excludeBranches = branches/cpstr
excludeBranches = branches/cpstrnew
excludeBranches = branches/ctypes
excludeBranches = branches/dodi
excludeBranches = branches/florian
excludeBranches = branches/foxsen
excludeBranches = branches/fcl-web_joost
excludeBranches = branches/generics
excludeBranches = branches/genfunc
excludeBranches = branches/janbruns
excludeBranches = branches/linker
excludeBranches = branches/newthreading
excludeBranches = branches/peterjan
excludeBranches = branches/ssa
excludeBranches = branches/tg74/rtl
excludeBranches = branches/tg74/tests
excludeBranches = branches/tg74/utils
excludeBranches = branches/unitrw
excludeBranches = branches/wkrenn
excludeBranches = branches/FIXES_2_2

branches = branches/merged/*:refs/heads/merged/*
branches = branches/joost/*:refs/heads/joost/*
branches = branches/laksen/*:refs/heads/laksen/*
branches = branches/maciej/*:refs/heads/maciej/*
branches = branches/olivier/*:refs/heads/olivier/*
branches = branches/paul/*:refs/heads/paul/*
branches = branches/*:refs/heads/svn/*
branches = branches/svenbarth/*:refs/heads/svenbarth/*
branches = branches/tg74/*:refs/heads/tg74/*

Set up user management and permissions.

Set up and automate github mirror