Tag Archives: Repository

Opensuse Leap 15.4 – Online Upgrade from Leap 15.3 on an Encrypted Laptop

Posted on by

After my retirement I was overwhelmed by a lot of typical German bureaucracy. But last weekend I used some time to start the long overdue upgrade of my old laptop from Opensuse Leap 15.3 to Leap 15.4. (The support for Leap 15.3 ended the at the end of 2022.)

I am always a bit afraid of upgrading my old laptop. It has a somewhat complicated configuration:

Its LVM volumes are fully encrypted with LUKS 2. It is an Optimus-System – and in the past it was not always easy to switch from the integrated Intel graphics card to the dedicated Nvidia card. Instead of Bumblebee I have used Opensuse’s Prime-Select with Leap 15.3. I use KDE as my graphical desktop environment. On Leap 15.3 I did not yet apply Wayland – but I intend to switch to Wayland with Leap 15.4. For some of my activities I also use Blender with full OpenGL support in form of a Flatpack installation. Furthermore, the laptop is used for both Machine learning, i.e. Python development, as well Web-development based on LAMP. So, it hosts a variety of services you normally find on servers. In addition we have KVM and VMware WS Pro installations. So, there are a lot of things which can go wrong. The Nvidia card is also an old one – a GT 645M which cannot be run with the latest generation of Nvidia drivers.

The good message is: The upgrade from leap 15.3 to 15.4 went very smoothly. At least regarding the things I was interested in. Below I describe the steps I have taken to upgrade. With some modifications you should be able to adapt it to your situation.

Backup of the encrypted LVM volume mounted on “/”

On my desktop PCs with Opensuse-installations, which I use for daily work, I follow a two-fold “backup”-policy ahead of upgrades: I copy my root-volume/partition to another LVM-volume or partition, and make it bootable in parallel to the existing installation. Reason: I want to be able to quickly switch to my present installation in case of trouble. As I have all of my personal and project data on separate LVM volumes with dedicated backups, the root-volume is the only one which I really must take care of. Therefore, I also copy it to a backup file on an external disk. For all data volumes I have a separate backup routine.

On my laptop I am a bit more relaxed: I just copy the volume mounted on “/” to an external disk. I have no second bootable installation on some other encrypted volume on the laptop. This means that I must boot a Live system or a Rescue system to make a backup of the unmounted “/”-volume.

For my purposes the Leap 15.3 “Rescue System”, which you can find on an DVD-ISO-image for the installation of Leap 15.3, was sufficient. You get the ISO image for such a DVD from opensuse.org and can burn it onto a DVD. The steps afterward were as follows:

  1. Boot your Leap 15.3 system. Check, on which partition or LVM volume your (encrypted) root-filesystem resides. Use e.g. YaST’s partitioner or gparted for this purpose. Shut down.
  2. Insert the DVD, select a boot menu, select the DVD, start from it, select “More …” in the GRUB-like menu, then select the DVD with the “Rescue System” and boot it.
  3. Login as root (no password required). Check that a tmpfs is mounted on / – and not some real partition.
    Note: The root-filesystem of our Leap-installation is NOT mounted on “/” of the rescue system. When I speak of the “root-filesystem” below I always refer to the filesystem containing the operative system of our current Leap 15.3 installation and not the root-fs of the rescue system.
  4. Check with command blkid what the device names of all accessible partitions and LVM volumes are. You should see encrypted and other volumes/partitions of your laptop disks/SSDs there.
  5. Plugin an external backup USB-disk. blkid should now also show the partitions on this disk, too.
  6. Mount the target filesystem of the external disk, where you want to place your backup, onto “/mnt” in your booted rescue system. Check the available space. In my case (with sdc being the external disk) : 
    tty1:rescue:~ # mount /dev/sdc2 /mnt
tty1:rescue:~ # df -h 
..
/dev/sdc2     825G   78G   706G     10%   /mnt 
...
  7. Locate your Leap 15.3 root-filesystem. In my case the root-filesystem of the laptop is an LUKS2-encrypted LVM available as “/dev/mapper/vgb-lvb2”. Note: You must know in advance, i.e. from your Leap 15.3 setup, where your root-filesystem resides.
  8. We now use the command “dd” to copy the root-filesystem onto a restorable image file. In my case: 
    dd status=progress if=/dev/mapper/vgb-lvb2 of=/mnt/root_lap.img

After the backup of the (encrypted) root-fs of our Leap 15.3 installation we shut down the rescue system, remove the DVD and boot Leap 15.3 again.

Check your RPM repositories – refresh and update

On the rebooted Leap 15.3 we check what we have of active repositories. In my case these were quite many:

(Ignore the double “mozilla” entry.)

Recommendation: You should make a similar screenshot and save it somewhere outside your laptop to later be able to restore all of the different repositories for Leap 15.4.

However, the most important repositories required to perform the upgrade are three update repositories:

  • One with renewed RPMs for the OSS,
  • one for Backports (backportet RPMs, e.g. security RPMS backportet from newer kernel or glibc related versions than the presently available versions on Opensuse Leap/SLES)
  • and one for renewed RPMs for the SLES version corresponding to the current Leap.

Update-repositories contain the latest RPMs of an Opensuse distribution. In our upgrade process we still deal with relevant update repositories for Leap 15.3. But we are soon going to exchange them with their Leap 15.4 counterparts.

Look out for the URLs of the current update repositories :

 * https://download.opensuse.org/update/leap/15.3/oss/
 * https://download.opensuse.org/<br>update/leap/15.3/backports/
 * https://download.opensuse.org/<br>update/leap/15.3/sle/ repo-sle-update

Leap 15.3 and 15.4 RPMs are binary compatible to those for the related SLES versions. In my case I had switched most of my Leap 15.3 RPMs to those of the update repo of SLES already a long time ago. If you have not done this yet you should do so now with the help of YaST.

I also directly deleted the repository for games as I regard it unimportant during an Upgrade.

Now, we refresh the lists of available RPMs and update to the latest versions. You can use the graphical YaST2 for this purpose or the command line:

mytuxlap:~ # zypper refresh

Then we perform an update of our Leap 15.3 RPMs to the latest available versions:

mytuxlap:~ # zypper update

In my case some of my Leap 15.3 repositories (for games, graphics, xfce and for snappy) were no longer available and could not be refreshed. I just had waited too long with my upgrade. But this resulted in no major problems during the upgrade.

After the update reboot and verify that your Leap 15.3 system still works.

Change repository URLs to contain the ${releasever} instead of an explicit version number

We change the URLs of our repositories now to contain ${releasever} instead of an explicit “15.3” in the URLs. It is easy to do this on the command line:

mytuxlap:~ # sed -i 's/15.3/${releasever}/g' /etc/zypp/repos.d/*.repo
mytuxlap:~ # sed -i 's/$releasever/${releasever}/g' /etc/zypp/repos.d/*.repo

The second command is just for being on the save side of the shell interpreter. I had previously already changed some of the repo URLs to include $releasever, but I want everything to consistently use ${releasever}.

Refresh for Leap 15.4 repository content – and eliminate some repositories

Next we start switching to the repositories for Leap 15.4. The first step is a refresh on the command line, but now for the Leap 15.4 repos. We can do this with the help of the variable ${releasever} in the following form:

mytuxlap:~ # zypper --releasever=15.4 refresh

Note that this does not yet change our repositories themselves, yet, but just the local content information. It gets replaced by lists about the contents of the Leap 15.4 repositories.

In my case this refresh process lead to errors. The reason was that some of the repositories which I used on Leap 15.3 had got a different path structure of the respective web resource below “download.opensuse.org/” for Leap 15.4. You have to ask the Opensuse people why they changed this. 

mytuxlap:~ # zypper --releasever=15.4 refresh
Warning: Enforced setting: $releasever=15.4
Retrieving repository 'nVidia Graphics Drivers' metadata ...........................................[done]
Building repository 'nVidia Graphics Drivers' cache ................................................[done]
Retrieving repository 'Packman Repository' metadata ................................................[done]
Building repository 'Packman Repository' cache .....................................................[done]
Retrieving repository 'Update 15.4' metadata .......................................................[done]
Building repository 'Update 15.4' cache..... .......................................................[done]
Retrieving repository 'graphics' metadata .........................................................[error]
Repository 'graphics' is invalid.
[openSUSE_Leap_${releasever}_1|https://download.opensuse.org/repositories/graphics/openSUSE_Leap_15.4/] Valid metadata not found at specified URL
History:
 - [openSUSE_Leap_${releasever}_1|https://download.opensuse.org/repositories/graphics/openSUSE_Leap_15.4/] Repository type can't be determined.

Please check if the URIs defined for this repository are pointing to a valid repository.
Skipping repository 'graphics' because of the above error.
Retrieving repository 'mozilla' metadata ...........................................................[done]
Building repository 'mozilla' cache ................................................................[done]
Retrieving repository 'XFCE' metadata .............................................................[error]
Repository 'XFCE' is invalid.
[openSUSE_Leap_${releasever}_3|https://download.opensuse.org/repositories/X11:/xfce/openSUSE_Leap_15.4/] Valid metadata not found at specified URL
History:
 - [openSUSE_Leap_${releasever}_3|https://download.opensuse.org/repositories/X11:/xfce/openSUSE_Leap_15.4/] Repository type can't be determined.

Please check if the URIs defined for this repository are pointing to a valid repository.
Skipping repository 'XFCE' because of the above error.
Retrieving repository 'Libdvdcss Repository' metadata ..............................................[done]
Building repository 'Libdvdcss Repository' cache ...................................................[done]
Retrieving repository 'Update repository of openSUSE Backports' metadata ...........................[done]
Building repository 'Update repository of openSUSE Backports' cache ................................[done]
Retrieving repository 'Non-OSS Repository' metadata ................................................[done]
Building repository 'Non-OSS Repository' cache .....................................................[done]
Retrieving repository 'openSUSE-Leap-15.4-Oss' metadata ............................................[done]
Building repository 'openSUSE-Leap-15.4-Oss' cache .................................................[done]
Retrieving repository 'Update repository with updates from SUSE Linux Enterprise 15' metadata ......[done]
Building repository 'Update repository with updates from SUSE Linux Enterprise 15' cache ...........[done]
Retrieving repository 'Aktualisierungs-Repository (Nicht-Open-Source-Software)' metadata ...........[done]
Building repository 'Aktualisierungs-Repository (Nicht-Open-Source-Software)' cache ................[done]
Retrieving repository 'snappy' metadata ............................................................[done]
Building repository 'snappy' cache .................................................................[done]
Some of the repositories have not been refreshed because of an error.

Then I changed again to the repository administration of YaST and simply deleted the problematic repos. We will care for their new URL later.

Note: The fact that we may have RPMs from missing repos during the upgrade is later on compensated by allowing for a “vendor change” – which means a repository change. See below.

After having eliminated problematic repos we get a successful refresh for the contents of remaining 15.4 repositories on the command line:

mytuxlap:~ # zypper --releasever=15.4 refresh
Warning: Enforced setting: $releasever=15.4
Repository 'nVidia Graphics Drivers' is up to date.                                     
Repository 'Packman Repository' is up to date.                                          
Repository 'mozilla' is up to date.                                                     
Repository 'Libdvdcss Repository' is up to date.                                        
Repository 'Update repository of openSUSE Backports' is up to date.                     
Repository 'Non-OSS Repository' is up to date.                                          
Repository 'openSUSE-Leap-15.4-Oss' is up to date.                                      
Repository 'Update repository with updates from SUSE Linux Enterprise 15' is up to date.
Repository 'Aktualisierungs-Repository (Nicht-Open-Source-Software)' is up to date.     
Repository 'snappy' is up to date.                                                      
All repositories have been refreshed.

Download of the RPMs without applying them, yet

The next step is to download the RPMs from the Leap 15.4 repos and save them in a cache for the later upgrade process. On a TTY or a root terminal window 

mytuxlap:~ #  zypper --releasever=15.4 dup --download-only --allow-vendor-change

The option “–download-only” avoids the installation of the new 15.4 RPMs. Also note the option “–allow-vendor-change”: If a RPM cannot be replaced a substitute from other major repositories will be used – if one is found.

Agree to the RPM setup displayed and the license conditions. Some 5 to 10 minutes later, after having downloaded everything, we must deactivate the graphical desktop.

Perform the Upgrade on an ASCII terminal (TTY)

On a system with both an integrated Intel card and a dedicated Nvidia card you may first want to decide which card driver you want to be loaded during the upgrade. You may use the Prime-Select Applet of Opensuse to switch to Intel on your desktop. Then logout and login again and check whether the Nvidia driver is no longer active.

Personally, I just kept the Nvidia card and the respective driver running. The resulting small problems were easy to overcome; see below. 

mytuxlap:~ # lsmod | grep nvidia
nvidia_drm             69632  5
nvidia_modeset       1204224  6 nvidia_drm
nvidia              35512320  281 nvidia_modeset
drm_kms_helper        303104  2 nvidia_drm,i915
drm                   634880  10 drm_kms_helper,nvidia,nvidia_drm,i915,ttm
mytuxlap:~ #

Important: Logout now of the graphical desktop to perform the Upgrade.

Move to an ASCII terminal (e.g. via Ctrl-Alt F1). There login as root. Type in “init 3” to stop your running X- or Wayland server. And then start the real upgrade and the respective rpm installation via “zypper –no-refresh –releasever=15.4 dup –allow-vendor-change” :

mytuxlap:~ # init 3 
mytuxlap:~ # zypper --no-refresh --releasever=15.4 dup --allow-vendor-change

You must again confirm the RPM configuration and the license conditions. Depending on your previous configuration several thousands of packages will then be installed the next 10 minutes or so from the preloaded and cached RPMs.

After all required RPMs have been installed just reboot by typing “init 6” on the command line.

My Leap 15.4 situation after reboot

In may case the systems behavior after reboot was a bit strange.

The good news is:

I experienced no problems with LUKS 2, grub2, initramfs and the second phase of the startup during which all of my other LUKS2-encrypted LVM volumes were decrypted, checked and mounted.

Off topic: Leap uses initramfs, but stores it at /boot/initrd.

The whole startup process worked like before: I get asked for the LUKS2 decryption key directly after starting the boot process, then the graphical grub2 menu comes up and I can start the primary phase of the boot process based on initramfs. In my installation, due to security precautions, I was asked to provide the decryption key once again before the second boot phase on the real root-filesystem started. (Off topic: There are configuration tricks to circumvent the 2nd request for the LuKS2 key, but my personal opinion is that the asking a second time enhances security a bit. I cannot go into the related details of a LUKS 2 configuration here.)

The bad news is:
The behavior of the Optimus environment was not consistent. Although the Nvidia RPMs had been shifted to those from the Nvidia community repository for Leap 15.4 after the reboot the Intel i915 was loaded – and I did not manage to activate the Nvidia driver. Also bbswitch interfered with my trials and shut down the Nvidia card:

The warm reboot directly after the upgrade seemed to work without major error messages (with the exception of an expected VMware related error; see below). The startup process eventually led to graphical login screen of sddm.
After login the applet for Prime-Select told me that Nvidia was active.

However, after shutting the laptop down completely and starting it via a cold boot I saw that the laptop’s LED signalling the activation of Nvidia was off (more precise showing a blue instead a red color). The Intel driver i915 was loaded with the start of the sddm login screen. Afterward the X11-KDE/Plasma combination actually worked perfectly with it. As did the combination Wayland and KDE Plasma; see below.

But at least for work with Blender I do need an active Nvidia card on the desktop. So, how to get it running?

Optimus – and a small problem with the Nvidia card

When I turned to a TTY and issued “init 3” I, actually, could activate the NVidia card via

mytuxlap:~ # tee /proc/acpi/bbswitch <<< ON

And I also could load the Nvidia driver by

mytuxlap:~ # modprobe nvidia

In addition 

mytuxlap:~ # prime-select nvidia

seemed to be accepted by the system.

However, when I afterward wanted to start the graphical desktop again via “init 5” I experienced that the Nvidia card was directly deactivated and that the Nvidia driver, therefore, could not work or be reloaded.

What a stupid situation! Obviously, the configuration of bbswitch had not been aligned correctly with prime-select and Nvidia during Upgrade.

Solution
In the end the solution was simple: I turned to a TTY, issued “init 3”, activated the Nvidia card, loaded the present driver and used the ASCII version of YaST (not graphical yast2) to reinstall (= update unconditionally) the Nvidia drivers from the Nvidia repository

I had to pick the G05-drivers as my graphics card is rather old. Note that the driver version 470 is also relatively old and has been reported to have some problems with the display manager Wayland.

After reboot everything then already worked as expected:
The Nvidia card was activated from the start and used for the graphical desktop afterwards. And I could use the Prime-Select Applet to switch to the Intel Driver with a subsequent logout from the KDE desktop and then a re-login. With Intel the Nvidia card got deactivated – which is very reasonable as it reduces the power consumption and heat generation of the laptop.

You may also check if things are already OK after a re-installation of the Nvidia drivers. The probably important thing is that during the reinstallation mkinitrd is started in the background and dracut is forced to re-configure the initramfs – this time with a loaded Nvidia driver.

If things still do not work in your case: Check that you have blacklisted the Nouveau driver in file “/etc/modprobe.d/50-blacklist.conf” and/or “/etc/modprobe.d/nvidia-default.conf” with entries

blacklist nouveau
options nouveau modeset=0

Then stop the graphical target again: Go to a terminal (Ctrl-Alt-F1), use “init 3” and try 

mytuxlap:~ # init 3 
mytuxlap:~ # tee /proc/acpi/bbswitch <<< ON
mytuxlap:~ # modprobe nvidia

This should work. Then

mytuxlap:~ # mkinitrd

Then reboot. On the graphical desktop (probably still using the Intel driver) open a root terminal window. Try

  
mytuxlap:~ # prime-select nvidia

Log out from the graphical desktop, watch the laptop LED indicating the activation of the Nvidia card (should now show that Nvidia is on), log in and check that the Nvidia driver was loaded:

mytuxlap:~ # lsmod | grep video

This should give you something like:

mytuxlap:~ # lsmod | grep nvidia
nvidia_drm             69632  7
nvidia_modeset       1204224  16 nvidia_drm
nvidia_uvm           1138688  0
nvidia              35512320  980 nvidia_uvm,nvidia_modeset
drm_kms_helper        303104  2 nvidia_drm,i915
drm                   634880  12 drm_kms_helper,nvidia,nvidia_drm,i915,ttm

Then test the reversion to the Intel driver via Opensuse’s prime-select applet. Should work now.

No cube animation for switching virtual desktops on KDE any more!

I had a brief look at other things on my new Leap 15.4 installation. Regarding KDE on Xorg the only thing I could complain about on Leap 15.4 was that the rotating cube animation for switching between virtual desktops was gone. This is due to decisions of the KDE people. So, Opensuse is NOT to blame for it. Personally, I think the loss of the animation is a pity, but it does not hinder any productivity, either. So, no big thing …

Wayland with KDE 5.24

A switch off the display server from Xorg to Wayland is a major step. I had been reluctant to use Wayland with Leap 15.2 and 15.3. Kernel, KDE and the Nvidia driver – all of their components must support Wayland. Unfortunately, Nvidia has for years been a major hinder in the support process – in contrast to Intel or AMD. So, I was a bit skeptical with Wayland, KDE/Plasma and Nvidia’s 470-driver on my old graphics card.

Positive results: KDE 5 started well. The startup of the desktop took longer time than with Xorg but completed successfully. Afterwards: No flickering of KDE, no problems with switching between virtual desktops or 3D desktop animations. Glxspheres worked. No problems with new windows of browsers like Firefox or Chromium – as were previously reported by others.

Best of all: My flatpack installation of Blender 3.3 did work very well.

Negative results: Nvidia-settings 470 did not work. Also, 3D-animation effects like wobbly windows appeared to have a slightly better performance on Xorg. After a session break (and the display of a protection screen with the option to relogin) a return to the KDE session lead to a strong white-flickering of the background. But this could be stopped by a mouse-click on the flickering background.

All in all: Even on my relatively old laptop I can productively use Wayland with Opensuse Leap 15.4 and KDE/Plasma 5.24 and Nvidia driver 470.

Leap 15.4 repositories with different locations than for 15.3

In general we can find available repositories at “https://download.opensuse.org”. The graphics repository has found a new location at 

https://download.opensuse.org/repositories/graphics/15.4/,

the XFCE at 

https://download.opensuse.org/repositories/X11:/xfce/15.4/.

Use Yast to add these repositories back to your list of active Leap 15.4 repos.

Still no actual Blender version on Leap 15.4

Note: Blender in a version above 2.82 is still not available for Leap 15.4. Which is a major shame. The glibc version is just too old for Blender 3.x. The only way out of this dilemma is a Flatpack or Snap based installation of Blender 3.4.
Such installations work, however, very well on Leap 15.4 – both with Xorg and Wayland.

Multimedia: Change system packages to RPMs of the packman repository

A broad range of multimedia tools and codecs require the packman repositories. What I typically do is to add a mirror with the packman repository, e.g. 

https://ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSE_Leap_${releasever}/

to the list of repositories, use YaST2 for the display of the contents of this repository and then click on the link “Switch system packages to the versions in this repository (Packman repository)”.

I tested some typical multimedia applications I use: Pulseaudio, PA equalizer, Clementine, VLC and TV channels on browsers. No problems.

What about Python?

My last development work on a desktop machine was done with Python 3.9, Jupyter notebooks and Eclipse. Leap 15.4 offers Python 3.6 as the standard. However, you can in parallel install either Python 3.9 OR Python 3.10. the OR is unfortunately exclusive. (The current Python version is 3.11).

I think I can live for some time with Python 3.10. So, I tested an installation of a virtual Python environment on Leap 15.4. The key to do so is to move to a directory where you want to implement your virtual environment – and install the relevant interpreter plus related basic directories. The following commands show an example: 

myself@mytuxlap:~> mkdir /projekte/GIT/ml_5
myself@mytuxlap:~> cd /projekte/GIT/
myself@mytuxlap:/projekte/GIT> virtualenv -p /usr/bin/python3.10 ml_5 
myself@mytuxlap:/projekte/GIT> cd ml_5
myself@mytuxlap:/projekte/GIT/ml_5> source bin/activate
(ml_5) myself@mytuxlap:/projekte/GIT/ml_5> pip install --upgrade pip
Collecting pip
  Using cached pip-23.0.1-py3-none-any.whl (2.1 MB)
Installing collected packages: pip
  Attempting uninstall: pip
    Found existing installation: pip 20.2
    Uninstalling pip-20.2:
      Successfully uninstalled pip-20.2
Successfully installed pip-23.0.1
(ml_5)  myself@mytuxlap:/projekte/GIT/ml_5> pip install jupyter      
Collecting jupyter
  Using cached jupyter-1.0.0-py2.py3-none-any.whl (2.7 kB)
...
...
(ml_5) myself@mytuxlap:/projekte/GIT/ml_5> jupyter-notebook 
...

This all works – but there are some (expected) errors regarding the jupyter_nbextensions_configurator. This is all well known – and also what has to be done to configure the jupyter_nbextensions correctly. This is no matter of leap 15.4.
Anyway, a Jupyter notebook will start in your default browser and you can start working with Python 3.10. I systematically added the needed libs and modules afterward with the help of pip. So, no majro problem with Python 3.10 on Leap 15.4!

What about PHP?

Well, Leap 15.4 offers an installation of either PHP7 or PHP8.0. I picked PHP8. But how does PHP 8 work together with a standard Apache2 installation on Leap 15.4?

Answer: It depends!

From the Apache point of view we would like to distribute the web server’s load on multiple Apache processes with a minimum consumption of RAM. Therefore, we would like to run Apache with an event based MPM module or just with the standard MPM-module. The problem is that this does not work with PHP. This problem already existed for lower PHP-versions than PHP 8.

You run into an error message like:

Apache is running a threaded MPM, but your PHP Module is not compiled to be threadsafe. You need to recompile PHP.

There are two solutions to this problem:

  • Switch to a prefork configuration of Apache 2.4 – and ignore the resulting RAM consumption
  • Use FastCGI and php8-fpm.

You also have to decide which method you want to use for changing the Apache2 configuration on Leap 15.4. You can remove RPMs or use a2enmod, a2dismod and maybe a2config, respectively. Relevant commands in our case would be “a2dismod mpm_worker”, a2dismod mpm_event” and a2enmod mpm_prefork”.

The easiest way, however, is to remove the RPMs “apache2-event” and/or “apache2-worker”, depending on what kind of configuration you have installed. I have no time to discuss the specific differences of these types of Multi-process setups of Apache2 here. To be able to activate prefork the RPM apache2-prefork must be installed. A reasonable RPM selection for a prefork variant would then look like this:

With this RPM selection you can just start Apache2 with the following modules successively: 

mytuxlap:~ # rcapache2 restart
mytuxlap:~ # a2enmod rewrite 
mytuxlap:~ # a2enmod -l
actions alias auth_basic authn_core authn_file authz_host authz_groupfile authz_core authz_user autoindex cgi dir env expires include log_config mime negotiation setenvif ssl socache_shmcb userdir reqtimeout php8 version mpm_prefork rewrite
mytuxlap:~ #

I.e.: For the simple prefork solution we can either try to disable the modules mpm_worker and/or mpm_event and activate “mpm_prefork” OR remove/install related RPMs.

But there is also another way to get PHP8 running – which is based on a FastCGI configuration of Apache2 together with the installation of a service for php8, namely php8-fpm. Personally, I have not yet tried a fast-cgi / php8-fpm combination on Leap 15.4. But I intend to describe the setup soon in this blog. In the meantime, please, check the information at the following links. It is given for other operative systems, but an adaption is straightforward.

Note: php-fpm is a service which must be started on your system via systemd’s command “systemctl”.

Digital ocean on PHP-fpm and Apache2 for Ubuntu 18
Digital Ocean on PHP and BSD
Digital ocean on PHP-fpm and Apache2 for Ubuntu 20

VMware and KVM

KVM works on leap 15.4 wwithout problems. I could directly start an existing qemu-virtualized Debian installation.

VMware WS also works on Leap 15.4. But you must have a version > WS 16.2.3 available. I updated to WS 16.2.5 by installing the bundle “VMware-Workstation-Full-16.2.5-20904516.x86_64.bundle”. Afterward I could start both VMware-virtualized Windows 10 and Win 7 installations on a Leap 15.4 KDE desktop without any problems.

Conclusion

The Upgrade from Opensuse Leap 15.3 to Leap 15.4 (with a KDE desktop) works without major problems even on older laptops with old Nvidia mobile graphics cards. Its a bit irritating that some Leap repositories got a new location with Leap 15.4 – but this can be fixed after the Upgrade.

A big positive surprise was that KDE 5.24 worked with Wayland even on my old Nvidia GT 645M card. A current Blender version MUST, unfortunately, be installed via Flatpack. Python 3.10 and PHP 8.0 are supported. KVM and VMware WS 16.2.5 pose no problems on Leap 15.4.

Happy working with Leap 15.4!

Links

Wayland vs. Xorg
https://linuxiac.com/ xorg-x11-wayland-linux-display-servers-and-protocols-explained/

Apache2 and PHP8
https://bbs.archlinux.org/ viewtopic.php?id=178124

 

Ceterum censeo: The worst fascist, war criminal and killer living today is the Putler. He must be isolated at all levels, be denazified and sooner than later be imprisoned. A president who orders the systematic destruction of civilian infrastructure must be fought and defeated because he is a permanent danger to basic principles of humanity. He must be brought to justice in front of an international court. Long live a free and democratic Ukraine!

 

Erste Schritte mit Git für lokale und zentrale Repositories unter Eclipse – II

Posted on by

Im letzten Blog-Post

Erste Schritte mit Git für lokale und zentrale Repositories unter Eclipse – I

hatte ich ein einfaches Szenario beschrieben, das regelmäßige Wechsel zwischen mobiler und ortsgebundener Entwicklungsarbeit beinhaltet und gerade im Leben von Freiberuflern immer wieder auftritt. Versionskontrolle erfordert im Zuge solcher Wechsel das Arbeiten mit lokalen und zentralen Repositories sowie systematische Abgleichoperationen zwischen solchen Repositories. Git ist für derartige Szenarien gut geeignet. Um entsprechende Experimente durchführen zu können, haben wir im letzten Post unser einfaches Wunschszenario in durchzuführende logische Schritten untergliedert.

Unser Ziel ist nun eine Abbildung der identifizierten Schritte in eine Git-Versionsverwaltung unter der IDE Eclipse. Daraus ergaben sich konkrete Aufgabenstellungen für Tests. In diesem Post befassen wir uns mit den ersten drei der identifizierten Aufgaben:

  • Aufgabe 1: Erstellen eines lokalen Git-Repositories auf dem PC.
  • Aufgabe 2: Klärung: Wo liegt der “Working Tree”? Welchen Verzeichnisbaum zeigt Eclipse?
  • Aufgabe 3: Einbringen des Inhalts des Projektverzeichnisbaums in den Master-Branch des lokalen Repositories. Initiales Commit.

Ich setze für das Verständnis der nachfolgenden Ausführungen einige Begrifflichkeiten voraus, die ich im letzten Blog-Post dieser Serie erläutert habe. Da es sich hier um einen Linux-Blog handelt beschreibe ich alle Schritte zur Lösung der Aufgaben für eine Linux/Eclipse-Umgebung, Linux-Verzeichnisbäume und, soweit erforderlich, Linux-Shell-Kommandos. Vermutlich lässt sich das Meiste aber auch direkt auf eine MS-Umgebung übertragen.

Abgrenzung “Eclipse Workspace” versus “Git Workspace”

In deutschsprachigen Büchern zu Git ist oft die Rede von einem (Git-) “Workspace”. Andererseits gibt es aber auch unter Eclipse “Workspaces”. Diese sollten wir im Folgenden begrifflich auseinanderhalten:

  • Eclipse Workspace: Ein Eclipse Workspace verwaltet eine Ansammlung von mehreren Projekten und zugehörige Dateien in projektspezifischen Verzeichnissen. Für den gesamten Eclipse Workspace können verschiedene grundlegende Eclipse-Eigenschaften (Settings) projektübergeordnet eingestellt werden. Ich kürze einen Eclipse-Workspace nachfolgend mit EWS ab. Ein EWS ist regelmäßig mit einem zugehörigen Verzeichnis verbunden. Das schließt aber definierte Links in weitere zugeordnete Verzeichnisse nicht aus. Im Besonderen müssen die Projektdateien nicht zwingend in einem Verzeichnis unterhalb des Workspace-Verzeichnisses beheimatet sein. Die EWS-spezifischen Eclipse-Einstellungen werden jedoch in versteckten Dateien/Unterverzeichnissen des EWS-Verzeichnisses hinterlegt. Solche speziellen Dateien/Verzeichnisse eines EWS wird man später nicht unbedingt in einem GIT-Repository erfassen wollen, da sie typischerweise Anweisungen beinhalten, die für eine Eclipse-Version spezifisch sind; ein abgleichender Transfer auf ein anderes System mit einer älteren Eclipse-Version könnte dann zu Problenmen auf der Eclipse-Ebene führen.
  • Git-Workspace: Ein Git-Workspace bezieht sich auf Dateien einer Verzeichnisstruktur, deren Änderungshistorie in einem Git-Repository im Sinne einer Versionierung aufgezeichnet und verwaltet wird. Ich kürze nachfolgend einen Git-Workspace mit GWS ab. Ein GWS besteht typischerweise aus einem reinen Repository-Bereich unterhalb eines speziellen Verzeichnisses “.git” und einem sog. “Working
    Tree    “, dessen Dateien eine definierte Code-Version auf einem Entwicklungs-“Branch” (-Zweig) beinhalten. Auf der Eclipse-Ebene entspricht der Working-Tree typischerweise der Verzeichnis-Struktur eines Projektes mit den dazu gehörigen aktuellen Code-Dateien.

Vorbereitende Schritte

Bevor wir uns an die Lösung unserer Aufgaben machen, müssen wir je nach Ausgangssituation ein paar vorbereitende Schritte treffen. Für diese und auch für nachfolgende Aktionen gilt:

Wir legen uns vorab immer eine Sicherheitskopie des gesamten EWS und ggf. auf Datei- oder Ordnerebene verlinkter anderer Eclipse Workspaces an. Ferner sichern wir vor Experimenten mit Dateien eines realen Projekts evtl. existierende SVN-Repositories, die mit diesem Projekt verbunden sein mögen.

Vorbereitender Schritt 0 – Git und das Eclipse EGit-Plugin installieren

Auf unserem Linux-PC installieren wir zunächst das für die jeweilige Distribution verfügbare Git-Paket. Wir erhalten damit u.a. auch Zugriff auf CLI-Kommandos, die im Zuge der Repository-Verwaltung eingesetzt werden können. Die Kenntnis solcher Kommandos ist übrigens nützlich, auch wenn man – wie ich – grafisch Bedien-Elemente einer IDE verwenden will. (Man kann unter Linux eine Git-basierte Versionsverwaltung von Projekten auch ausschließlich auf der Kommandozeile betreiben.) Wer Lust hat, kann neben Git selbst gleich auch noch die Pakete “gitg”, “Qgit”, “Giggle” und ggf. auch “git-cola” oder “cola-git” installieren. Jedes dieser Pakete bietet eine eigene unabhängig von Eclipse nutzbare GUI für Git mit mehr oder weniger Komfort und Funktionalität an.

Für Eclipse selbst gibt es ein Git-Plugin namens EGit (welches wiederum JGit benötigt). EGit sollte im Haupt- oder Update-Repository der jeweiligen Eclipse-Installation (hier Neon 3) in einer passenden Version verfügbar sein. Für den aktuellsten Stand greift man auf folgendes Eclipse-Repository zu: 

http://download.eclipse.org/egit/updates.

Von dort können wir EGit genauso wie andere Eclipse Plugins auch installieren. Je nachdem, ob man vor hat, später auch externe GitHub-Dienste zu nutzen und/oder Mylyn einzusetzen, kann die Installation weiterer Plugins von Interesse sein. Das folgende Bild zeigt, welche Git-bezogenen Pakete ich selbst unter einem aktuellen Eclipse Neon 3 installiert habe:

Ich gehe auf die relativ trivialen Installationsschritte unter Linux/Eclipse nicht näher ein. Siehe bei Bedarf aber:
http://www.vogella.com/ tutorials/ EclipseGit /article.html #installation-of-git-support-into-eclipse
https://www.eclipse.org/ forums/ index.php/ t/273443/

Vorbereitender Schritt 1 – Lösen eines PHP-Projektes von seiner SVN-Anbindung

Das nachfolgende Bild zeigt die relativ simple Verzeichnis und Projektstruktur eines EWS namens “ecl_alienx”; das zugehörige Verzeichnis auf dem Linux-PC ist “/projekte/ecl_alienx”.

Das dortige Test-Projekt “alien1” und seine Verzeichnisse/Dateien sind unterhalb des Ordners “/projekte/ecl_alienx/alien1” beheimatet. Eclipse-Puristen würden diese Ortswahl für die Programmdateien mit einiger Berechtigung kritisieren. Das ist uns hier aber egal; es wird sich sowieso gleich ändern.

Den Bildinformationen entnehmen wir: Das Projekt ist offenbar noch mit einem Subversion-SVN-Repository verbunden. Wir lösen diese SVN-Verbindung nun über den Disconnect-Befehl, den wir unter dem Kontexmenüs des Projektes finden: => “Team => Disconnect”.

Dabei löschen wir auch die SVN-Metainformation in den “.svn”-Dateien jedes Projekt-Verzeichnisses. Das ist zwar nicht zwingend erforderlich; ich möchte bei den nachfolgenden Git-Experimenten aber keinen SVN-Ballast mit mir rumschleppen. (Das SVN-Repository selbst wird bei dieser Aktion übrigens nicht gelöscht).

Unser Projekt ist jetzt unbelastet von jeglicher Versionsverwaltung.

Für die weiteren Schritte lohnt es sich, den View “Git Repositories” (z.B. im unteren Bereich des Eclipse Desktops) permanent geöffnet zu halten. Dieser View ist anfänglich natürlich noch leer; bei späteren Git-Aktionen ist ein kontrollierender Blick in diesen View immer informativ und hilfreich. Öffnen kann man den View über den Eclipse Menüpunkt “Window => Show View => Others => Git => Git Repositories”.

Lösung der Aufgabe 1 – Erstellen eines lokalen Repositories

Als erstes erstellen wir mittels einer Shell oder einem Dateimanager außerhalb des EWS ein Verzeichnis für unseren künftigen GWS inkl. eines lokalen GIT-Repositories. In meinem Testfall etwa unter “/projekte/GIT/alien1“. Dann öffnen wir das Kontext-Menü unseres Projektes erneut und wählen den Punkt “Team => Share Project“:

Im nächsten Dialogfenster klicken wir auf den “Create“-Button und geben im nachfolgenden Subdialog den vorgesehenen Zielort des Repositories an:

Achtung:
Das Bild deutet bereits an, dass EGit deutlich mehr vor hat, als nur ein Git-Repository anzulegen. Vielmehr sollen alle Unterverzeichnisse unseres Projektes in eine Verzeichnisstruktur im Targetverzeichnis “/projekte/GIT/alien1” umgezogen werden. Wir werden gleich sehen, dass dadurch der sog. “Working Tree” unter dem Directory “/projekte/GIT/alien1/alien1/” im Workspace angelegt wird; der Working Tree besteht initial also aus den ursprünglichen Projekt-Verzeichnissen und -Dateien des EWS.

Im Targetverzeichnis “/projekte/GIT/alien1” wird parallel auch das eigentliche Git-Repository als Teil des GWS angelegt. Die erforderlichen Repository-Strukturen (Unter-Verzeichnisse für verschiedene Informationen, Object-Datenbanken mit Blobs, Indices, …) findet man anschließend in einem Verzeichnis “/projekte/GIT/alien1/.git“.

Hinweis: Ich würde an dieser Struktur des GWS nichts ändern!

  • Git erlaubt zwar grundsätzlich eine Trennung des Dachverzeichnisses
    für das “.git”-Repository-Verzeichnis vom Dachverzeichnisses für den “Working Tree”. Man kann dies etwa über CLI-Kommandos erzwingen. Nach meiner Erfahrung bringt eine solche separate Lagerung des Repositories und des Working-Trees an unterschiedlichen Orten EGit aber bei weiteren Aktionen außer Tritt. Also den Umzug der Verzeichnisstruktur an die angezeigten Position bitte zulassen!
  • Bitte achtet auch darauf, dass der Pfad zum künftigen “.git”-Verzeichnisses in eurem Dialog wirklich so ähnlich aussieht wie dargestellt. Man gerät durch Unachtsamkeit relativ schnell in eine Situation, in der man “.git” nachher unterhalb des Hauptverzeichnisses des Working Trees wiederfindet. Auch das ist technisch zwar zulässig, hätte später aber mehrere unangenehme Seiteneffekte, auf die ich an dieser Stelle nicht eingehen will. Also: Bitte darauf achten, dass das “.git”-Verzeichnis auf derselben Ebene der Verzeichnisstruktur platziert wird wie der zu erzeugende Working Tree. !

Jetzt klicken wir endlich auf den Button “Finish”; je nach Größe des bereits vorhandenen Projektverzeichnisses dauert das Verlagern der Dateien ggf. ein wenig. Schließlich sind aber sowohl das Repository unter dem Directory “.git” wie auch der Working Tree am vorgesehenen Bestimmungsort vorhanden.

>Lösung der Aufgabe 2 – Working Tree und Verzeichnisstruktur

Das Ergebnis sollte sich im PHP-Explorer bzw. im View “Git Reposiories” wie folgt darstellen:

Im unteren Teil sehen wir einen Ausschnitt des “Git Repository”-Views. Bereits hier erkennen wir deutlich den Aufbau unseres neuen GWS. Der Working Tree ist dort als solcher bezeichnet und sein Pfad ist angegeben. Ein Dateimanager bestätigt die gewünschte Verzeichnishierarchie:

Glückwunsch! Wir haben unser erstes Git-Repository samt Working Tree erstellt. Durch die Parametrierung bei der Erstellung des Repositorys und durch die beiden obigen Abbildungen haben wir neben Aufgabe 1 auch schon Aufgabe 2 gelöst.

Das Repository ist in diesem Zustand aber erst vorbereitet. Noch sind dort keine Inhalte oder Verionsobjekte angelegt ….

Git-Smart-Icon-Leiste aktivieren

Um nachfolgend etwas einfacher mit dem Repository und dem Commit neuer Dateien arbeiten zu können, beschaffen wir uns eine Smart-Icon-Leiste für Git-Operationen im Kopfbereich von Eclipse. Das erreichen wir in zwei Schritten:

  • Klick auf den Eclipse-Menüpunkt “Window => Perspective => Customize Perspective … “. Dort unter dem Reiter “Action Set Availability” die Punkte “Git” und “Git Navigation Actions” aktivieren.
     
  • Danach aktivieren wir unter dem Tab “Menu Visibility” den Punkt “Git”:
     

Als Ergebnis erhalten wir folgende Leiste:

>Lösung der Aufgabe 3 – Master-Branch und initiales Commit

Der weiter oben dargestellte View “Git-Repositories” weist uns neben dem Repository-Symbol im Moment explizit darauf hin, dass noch keine HEAD-Version existiert. Wie auch? Im “Branches”-Bereich ist unter dem Punkt “Local” ja noch nicht mal ein (Master-) Branch zu finden (s. den vorhergehenden Blog-Post). Es gibt im Moment noch überhaupt keinen Branch!

Unter Git muss man Verzeichnisse und Dateien explizit für die Berücksichtigung in der Versionsverwaltung markieren. Die kleinen Fragezeichen in den Verzeichnis-Icons im PHP-Explorer deuten an, dass dies bislang noch für keines der vier Hauptverzeichnisse unseres Test-Projektes geschehen ist. Ein “gt;”-Symbol nach den Verzeichnis- bzw. auch nach einem Datei-Namen deutet ferner an, dass es eine Änderung gibt, die noch nicht per Commit im Repository erfasst wurde: Der aktuelle Inhalt jeder Datei stellt aus Sicht von Git offenbar eine Art erste (initiale) Änderung dar. Wir würden das Symbol bei jeder Datei unterhalb der Verzeichnisse sehen.

Später werden wir das “>”-Symbol natürlich genau an denjenigen Dateien/Verzeichnissen entdecken, die jemand seit dem letzten Commit modifiziert hat. Das ist beim Einsatz von Subversion ganz genauso. Einen kleinen Unterschied zu SVN gibt es allerdings doch, und der macht sich dadurch bemerkbar, dass das Verzeichnis “uploads” kein “>”-Symbol aufweist: Der Grund dafür ist, dass das Verzeichnis leer ist. Das ist ein Hinweis darauf, dass Git keine separate Versionsverwaltung für Verzeichnisse als Repository-Objekte vornimmt. Verzeichnisse sind lediglich ein Art Attribut der nach Versionen verwalteten Datei-Objekte!

Den aktuellen Repository-Zustand könnte man im Git-Sprachgebrauch also etwa so zusammenfassen: Es ist bislang weder ein “Commit” zu den vorhandenen Dateien erfolgt, noch wurden die in Verzeichnissen organisierten Dateien überhaupt für eine Indizierung und Verwaltung in einem Branch und damit auch der Git-Objektdatenbank vorgesehen. Wir ändern das nun in zwei separaten Schritten:

Schritt 1 – Einbeziehen der Verzeichnisse und ihrer Dateien in die Versionsverwaltung: Wir markieren unsere 4 Projektverzeichnisse des Beispiels “alien”, “includes”, “interpreters”, “uploads” im PHP- oder Projekt-Explorer. Dann klicken wir in der Git-Icon-Leiste auf das grüne Kreuz. Danach müssen warten, bis sich das Dialogfenster zu “Operation in Progress …” wieder schließt.

Die nächste Abbildung zeigt, dass sich die Mikro-Symbole an den Verzeichnissen nun geändert haben:

Der weiße Stern auf schwarzem Grund weist allerdings darauf hin, dass die Dateien in den Verzeichnissen immer noch keinen “Commit” erfahren haben.

Schritt 2 – Initialer Commit für alle erfassten Dateien:
Um für alle Dateien einen “Commit” einzuleiten, markieren wir unsere Verzeichnisse erneut und klicken dann auf das orange Repository-Symbol mit dem Pfeil von links nach rechts in der Git-Icon-Leiste; dieses Symbol befindet sich neben dem grünen Kreuz und symbolisiert einen Commit-Vorgang – unseren ersten im erstellten Repository.

Nach wenigen Augenblicken bietet sich uns dann folgendes Bild im sogenannten “Git Staging View“. Dieser View öffnet sich automatisch und listet Dateien/Verzeichnisse auf, die modifiziert wurden und für die endgültige Ausführung des Commits “vorgemerkt” sind. Man nennt das auch “Staging“.

Im linken Bereich sehen wir im Bereich “Unstaged Changes” Dateien (nur 2 von 5 sind sichtbar), die bislang nicht für Commits vorgemerkt wurden. Es handelt sich in unserem Fall um Eclipse-Konfigurationsdateien für das spezielle Projekt. Darunter sehen wir im Bereich “Staged Changes” allerdings die für das Commit vorgemerkten Dateien. In unserem Fall alle Projektdateien. (Es handelt sich offenbar um eine größeres Projekt, zu dem über 3000 einzelne Dateien beitragen.)

Im rechten Bereich des “Staging View” können (besser müssen) wir unseren Commit noch mit einem Kommentar verzieren. Unterhalb sollten auch Author und Committer angegeben werden; dabei sind bestimmte Formatanforderungen zu erfüllen, die wir nach einem Klick in das jeweilige Feld gefolgt von einem “Ctrl-Space” angezeigt bekommen. Die entsprechenden Werte lassen sich auch in den Eclipse-Preferences für Git hinterlegen. Man findet Git-Preferenzen wie üblich unter dem Menüpunkt “Window => Preferences => Team => Git”.

Wir klicken nun auf den Button “Commit“. Es wird jetzt eine erste Komplettversion im sog. “master”-Branch unseres Repositories erzeugt. Genauer: Zuerst wird der Master-Branch generiert; dann wird n einer ersten Projektversion auf diesem Branch der aktuelle Inhalt aller ausgewählten Projektdateien erfasst. Das Erzeugen der zugehörigen initialen Objekte des Repositories und deren Komprimierung dauert in meinem Fall wegen der großen Menge der Dateien ein paar Augenblicke.

Jeder Commit führt zu einem neuen Versionsstatus des gesamten Branches (sozusagen über alle modifizierten Dateien hinweg). Auf der Branch-Ebene entspricht ein Commit in seiner Gesamtheit somit einem eindeutigen Knoten (s. hierzu den letzten Post). Die Identität des Knotens wird durch einen eindeutigen Hash gekennzeichnet, dessen erste Buchstaben wir im Git-Repository-View auch angezeigt bekommen. Diesem Hash sind wiederum Hashes für die einzelnen erfassten Objekte (Dateien bzw. komprimierte Blobs zu deren Änderungen) zugeordnet. Auch die Änderungen selbst (bzw. zugehörige Objekte in einem Binärformat) werden also über Hashes identifiziert.

Im Git-Repository-View ergibt sich nach der Durchführung des Commits folgendes Bild :

Nun existiert offenbar der ersehnte lokale Master-Branch. Daneben erkennen wir die ersten alphanumerischen Zeichen seines Hashes (hier: 3659950) und die Anfänge unseres eben erstellten Kommentars.

Unsere Verzeichnis-Symbole im PHP-Explorer weisen nun zudem das kleine orangefarbene zylinderartige Repository-Symbol auf – damit wird angezeigt, dass die Dateien in den betroffenen Verzeichnissen ordnungsgemäß versioniert wurden. Das Fehlen von “>”-Symbolen an den Verzeichnissen, die Dateien enthalten, zeigt an, dass im Repository auch alles auf dem aktuellsten Stand ist.

Neben dem Verzeichnissymbol zum Haupt-Directory “alien1” unseres Projekts wird freundlicherweise dargestellt, welchem Branch der Inhalt des “Working Trees” gerade zugeordnet ist. (In realen Projekten wird es ja ggf. mehrere Branches geben). Der geneigte Leser wird nun sicher auch selbst beantworten können, warum das “>”-Symbol neben dem Hauptverzeichnis “alien1” nicht verschwunden ist.

Der interessierte Leser mag in einem eigenen Beispiel zudem mal einen Blick in das Verzeichnis “/…./.git/objects” werfen; man wird feststellen, dass auch dieses Verzeichnis nach dem initialen Commit mit vielen Dateien in einem Binärformat gefüllt wurde.
Nach unserem initialen Commit ist die komplette Information über den Inhalt der Projekt-Dateien also redundant vorhanden – einmal im “Working Tree” und auch in der Objektdatenbank des Repositories.

Nach weiteren Commits enthält das Repository aber deutlich mehr Informationen als der Working Tree: Der Working Tree spiegelt dann nur den Zustand wider, der zum geöffneten letzten Knoten des aktiven Branches gehört – plus ggf. zwischenzeitlich vorgenommene Änderungen, die noch nicht committed wurden. Das Repository hingegen enthält dann die gesamte bisherige Änderungshistorie. Dank Komprimierungstechnologie und der Speicherung inkrementeller Änderungen ist der Platzbedarf des Workings Trees über lange Zeit hinweg dennoch meist deutlich geringer als der Platzbedarf des Working Trees.

Zusammenfassung und Ausblick

Wir haben im Zuge dieses Artikels zu einem vorhandenen Projekt eine voll funktionsfähige lokale Versionsverwaltung unter Git eingerichtet, mit der wir nun weitere Experimente durchführen können. Wir haben dabei gesehen, dass ein Repository nach seiner Anlage auch gefüllt werden muss. Dazu sind Dateien für die Erfassung und Verfolgung in der Versionsverwaltung zu markieren. Ein Commit besteht im Grunde aus drei Phasen :

  • Phase 1: Auswahl und Staging der geänderten Dateien für die Durchführung des Commits.
  • Phase 2: Eingeben eines Kommentars zum Commit. Benennung des Autors und des Committers.
  • Phase 3: Technische Durchführung des Commits.

Ein Commit erzeugt einen eindeutig identifizierbaren Knoten in einem Branch. In einem initialen Commit werden der Master-Branch des Repositories und dessen erster Knoten erzeugt. Der Commit bzw. der korrespondierende Knoten im Branch sind durch einen eindeutigen Hash gekennzeichnet. Einem Commit sind ferner bestimmte (neu) angelegte Objekte im Verzeichnis “.git/objects” zugeordnet.

Im nächsten Blog-Post führen wir testweise einige Änderungen und zugehörige Commits durch. Wir betrachten dabei auch die Darstellung der Historie unter Eclipse. Zudem werfen wir einen ersten vergleichenden Blick auf die GUIs “GitG” bzw. “QGit”.

Erste Schritte mit Git für lokale und zentrale Repositories unter Eclipse – I

Posted on by

Seit Jahren arbeite ich unter Eclipse fast gewohnheitsmäßig mit SVN (Subversive Plugin und Polarion Connectoren) als Versionsverwaltungstool. Eine Frage, die mich dabei seit längerem verfolgt, ist:

Ist für Freiberufler wie mich, und damit in vielen Fällen für mobile Einzelkämpfer, trotz aller SVN-Affinität ein Wechsel auf Git sinnvoll? Woran kann man den Bedarf dingfest machen?

Steht ein Entwicklungsprojekt in einem überregional verteilten Team an, so setzen ja bereits viele andere Entwickler auch Git ein. Dann ist der Einsatz natürlich auch für mich unumgänglich. In der Situation befand ich mich aber noch nicht – deswegen habe ich eine ernsthafte Auseinandersetzung bislang auch immer wieder verschoben. Nun belasten mich ein paar Defizite von SVN aber zumindest für Entwicklungsaufgaben so, das ich das Thema wieder aufgreife.

Betrachten wir also mal eine sehr viel einfachere Situation als eine Entwicklung in einem verteilten Team. Nehmen wir an, das ich alleine etwas für einen Kunden entwickeln muss, aber den Kunden regelmäßig an einem anderen Ort (u.U. im Ausland) aufsuchen muss. Oder nehmen wir an, dass während der Entwicklungsarbeiten auch aus anderen gründen längere Abwesenheiten vom Arbeitsplatz-PC erforderlich sind, und in der Zwischenzeit am Laptop weitergearbeitet werden muss. Und gehen wir weiter von einer Situation aus, in der im Vor- und Nachfeld von Reisen der Status veränderter Projekt-Dateien regelmäßig versioniert und auf einfache Weise zwischen Arbeitsplatz-PC daheim und einem Laptop abgeglichen werden muss:

  1. Bewege ich mich zum Kunden, muss ich Dateien, die sich auf aktuell laufende Entwicklungsprojekte beziehen und an denen ich zuvor an meinem Arbeitsplatz gearbeitet habe, von meinem PC auf einfache automatisierte Weise auf einen Laptop transferieren. Dabei möchte ich aus entwicklungstechnischen Gründen (und in Beratungsprojekten z.B. zu Belegzwecken) immer die gesamte bisherige Versionshistorie der Dateien mit mir führen.
  2. Natürlich möchte ich answchließend zur Kontrolle weiterer Änderungen, die während der Reise anfallen, auf dem Laptop gerne ein lokales Versionsmanagement betreiben. Das gilt vor allem bei längerer Abwesenheit vom Heim/Firmenstandort. Und die während der Reise erreichten Zwischenstände möchte ich schon aus Backup-Gründen mit einem Repository im Internet abgleichen.
  3. Und natürlich sollen die auf dem Laptop erarbeiteten Ergebnisse nach dem Ende der Reise wieder in ein dortiges zentrales Repository des Haus-/Firmennetzes eingespielt werden. Von da dann wenn möglich auch weiter in ein lokales Repository auf meinem Arbeitsplatz-PC ..

Hier besteht also schon für einen Einzelkämpfer der Bedarf nach einer lokalen und einer zentraler Versionsverfolgung. Das bedingt zwangsläufig den Abgleich zwischen lokalen und zentralen Repositories zu sinnvoll gewählten Zeitpunkten. Will man solche Szenarien mit SVN abbilden steht man vor einem kleinen Dilemma, das erhebliche Klimmzüge erfordert.

SVN ist dafür gedacht, dass man sich mit einem (!) zentralen Server abgleicht. Der muss deshalb auch kontinuierlich erreichbar sein. Nun habe ich (gerade bei etwas längeren Auslandsaufenthalten) aber nicht immer eine Internetverbindung zur Verfügung. In einer solchen Situation bräuchte ich dann zwingend eine lokale Versionsverwaltung auf meinem Laptop, dessen Repository später mit Repositories mehrerer Server abgeglichen werden soll und muss. Das ist unter SVN wirklich ein Rezept für ein gediegenes Kuddelmuddel.

Unter Git ist das nach ersten Literaturstudien dagegen gut zu beherrschen. Git erlaubt das sichere Arbeiten mit einem lokalen und zentralen Repositories. In dieser Miniserie von Blog-Posts möchte ich deshalb für Interessierte
und Einsteiger, die Git unter Eclipse betreiben wollen, erste einfache Schritte beschreiben,

  • wie man lokale Repositorys mit Eclipse-Mitteln auf einem PC und auf einem Laptop aufsetzt,
  • wie man Repositories “cloned” und Clones zum Einrichten von Server-Repositories verwendet,
  • wie man ein lokales Repository dann mit einem ein zentralen Repository im Haus- oder Firmennetz verbindet
  • und gleichzeitig ein weiteres Repository im Internet als Backup- und Refernz-Repository benutzen kann.

Ich lasse dabei ein komplexes lokales und zentrales Feature- oder Release-Branching völlig außen vor. Um Release- und Feature-Branching kümmere ich mich evtl. in späteren Blog-Artikeln. Hier geht es nur um die Unterstützung eines quasi-sequentiellen Arbeitens an verschiedenen Geräten in folgendem Sinne:

Schritte eines Wunschszenarios für mobile Einzelkämpfer

  1. Entwicklung-/Dateiänderungen am Arbeitsplatz-PC. Versionierung mit Hilfe eines lokalen Repositorys auf dem PC
  2. => regelmäßiger Abgleich des Entwicklungsstandes auf dem PC mit einem zentralen Server-Repository im Hausnetz und einem zentralen Repository im Internet
  3. => Vorbereitung einer Reise: Abgleich des zentralen Server-Repositories mit dem lokalen Repositories eines Laptops
  4. => mobiles Arbeiten am Laptop und Versionsverwaltung mit einem dortigen lokalen Repository
  5. =>Abgleich neuer Versionsstände auf dem Laptop mit einem zentralen Repository im Internet
  6. => Rückkehr ins Firmennetz und Abgleich des Laptop-Repositories mit dem zentralen Git-Repository auf einem zuständigen Server des LANs
  7. => Abgleich zwischen Server-Repository und Arbeitsplatz-Repository
  8. => Arbeiten mit dem lokalen Repository am Arbeitsplatz und erneut Abgleich mit beiden Server-Repositories
  9. => Abgleich mit Laptop in Vorbereitung einer neuen Reise.

    10. Das ist ein denkbar einfaches Szenario, dass sich mit Hilfe einer IDE wie Eclipse nachbilden lassen sollte. Zur Vorbereitung benötigen wir jedoch einige generell Git-Begrifflichkeiten. Daher greife ich nachfolgend die Arbeitsschritte nochmal aus Eclipse-Perspektive auf und führe dabei gleichzeitig ein paar zentrale Begriffe aus der Git-Welt ein, an die man sich sowieso gewöhnen muss, wenn man ein Git-Plugin unter Eclipse einsetzen will.

    Wir leiten aus der Neubeschreibung der obigen Arbeitsschritte unseres Wunschszenarios nebenbei Aufgaben ab, deren Lösung später zu einer systematischen Abbildung der gewünschten Prozesse unter Eclipse führen wird.

    Das Wunschszenario in Git-Begriffen

    Zur Vertiefung betrachten wir folgende Skizze:

    Bin ich im firmeneigenen Netz arbeite ich normalerweise auf einer Linux-Workstation. Dort ist etwa “Eclipse Neon 3” mit dem Git-Plugin (Egit) installiert. Die Entwicklungsarbeit ist in Form von (Eclipse-) “Projekten” organisiert, zu denen jeweils ein Dateibaum gehört. In meinem Fall tummeln sich dort typischerweise PHP-, HTML,-, CSS-, Javascript- und auch mal Python-Dateien.

    Für unser Beispielszenario ziehen wir später die Dateien eines konkreten Eclipse-Projektes namens “alien1” heran. Die zugehörigen Dateien liegen dabei unter 4 Haupt-Verzeichnissen: includes, admin, interpreters,
    uploads. Das Projekt wurde in einem Eclipse-“Workspace” namens “ecl_alienx” platziert. Die genannten 4 Verzeichnisse sind im Beispiel deshalb unter einem Verzeichnis “/projekte/ecl_alienx/alien1” zu finden.

    Man könnte nun darüber streiten, ob die Aufbewahrung der Programm-Dateien innerhalb des Eclipse-Workspaces sinnvoll ist. Wir unterlassen diese Diskussion aber, da wir die Verzeichnislokation im Rahmen des Git-Einsatzes sowieso ändern werden.

    Was wollen wir nun im Detail erreichen?
    Zur Versionsverwaltung möchte ich in unserem Wunsch-Szenario zunächst ein lokales Git-Repository auf dem Arebitsplatz-PC benutzen, bis ich der Meinung bin, dass erreichte Zwischenergebnisse auch auf einem zentralen (Git-) Repository eines Servers im Haus-/Firmen-Netz zur Verfügung gestellt werden sollten. Ggf. für den Zugriff durch andere Nutzer/Tester, aber auch für zentrale Backups.

    Lokal checke ich eine erreichte neue (Zwischen-) Version zunächst als sogenannten “Commit” in das Git-Repository meiner Workstation ein. Manchmal muss man in der SW-Entwicklung von einer bestimmten Version aus unterschiedliche, und für eine Weile divergierende Wege zu neuen Versionen gehen. Man erhält dann “Verzweigungen” der Versionsstände; wie in SVN auch bezeichnet man diese Zweige in Git als “Branches“. Branches können zum Beispiel als Feature- oder Release-Branches angelegt werden zur experimentellen Entwicklung von Features in einem separaten Zweig bzw. zur Konsolidierung eingefrorener Versionsstände angelegt werden. Andee Branches mögen etwa auch einer Continuous Integration dienen. Zu und zwischen Branches – also definierten Abzweigungen in der Versionshistorie – möchte man ggf. wechseln. Unter Git spricht man hierbei (abweichend von anderen Versionsverwaltungssystemen) von sog. Checkouts. Warum wird später klarer werden. Würde man z.B. vom Master-Branch zu einem anderen Branch namens “Branch2″ wechseln, so würde Branch2” zum sog. “aktiven Branch” des Repositories werden.

    Jeder Commit entspricht grafisch gesehen einem “Knoten” eines Branches (s. die Skizze weiter unten); ein Knoten symbolisiert einen bestimmte Versionsstand des Branches (also eine eindeutigen Kombination aus definierten Versionsständen aller für die Versionsverwaltung erfassten Dateien). Ein Knoten in einem Branch entspricht also genau besehen nicht nur dem punktuellen Commit, der zu seiner Erzeugung führte, sondern im Kern der ganzen Historie aller vorangegangenen Commits auf den erfassten Dateien – ausgehend von einem initialen Commit. Die Rückkehr zu einem älteren Versionsstand (Knoten) in einem Branch nennt man unter Git einen sog. “Reset“.

    Für Aktionen wie Commits, eine Historienverfolgung, Branching, Checkouts, Resets etc. sollte im Grunde gar kein Server erforderlich sein; ich will mit meiner lokalen Versionsverwaltung und dem zugehörigen Repository wenn nötig auch einen ganze Weile völlig autonom arbeiten können ohne irgendwelche Kollegen zu belästigen.

    So weit so gut. Nun eine Einschränkung:

    In unserem Szenario konzentrieren wir uns weitgehend auf sukzessive voranschreitende Versionen – oder “Knoten” – in genau einem Branch jedes eingesetzten Repositories. Der ursprünglich erzeugte, erste und native Branch eines jeden Repositories ist dessen sog. Master-Branch. Wir beschäftigen uns in dieser Blog-Post-Serie also primär mit dem Abgleich zwischen den “Master”-Branches verschiedener Repositories. Wir lassen dabei für unser Wunschszenario die gewollte Erzeugung von Branches (Entwicklungszweigen) und das Wechseln zu einem anderen als dem “Master”-Branch weitgehend außen vor.

    Die Verzeichnisstruktur, in der die Dateien eines Eclipse-Projektes organisiert werden, muss sich in einem geeigneten Äquivalent im Rahmen der
    Repository-Verwaltung widerspiegeln. Ein solches Äquivalent ist der sog. “Working Tree” eines Repositories. Wir werden sehen, dass auch der Working Tree eine Verzeichnisstruktur darstellt; diese entspricht ferner einer Momentaufnahme eines definierten Knotens auf dem “aktuellen Branch”; in unserem Beispiel also auf dem Master-Branch. Achtung: Checkouts und Resets führen zu Veränderungen der Inhalte von Dateien im “Working Tree”.

    Typischerweise kann es sich ein Versionsverwaltungssystem aber nicht leisten, unterschiedliche und vollständige Varianten aller Dateiinhalte in normaler Dateiform aufzubewahren, um die Historie zu erfassen. Git arbeitet hier (wie andere System auch) inkrementell und verwahrt Differenzen zwischen Dateizuständen; zudem wird komprimiert: Im Ergebnis entstehen so Blobs einer Art Objekt-Datenbank. Die Objekte wiederum lassen sich eindeutig identifizieren und werden definierten Zustandsknoten von Branches (und damit auch Commits) zugeordnet. Eine eindeutige Identifizierung sowohl von Objekten als auch Commits (Knoten) wird in Git über Hashes ermöglicht, zwischen denen dann Relationen hergestellt werden. Weitere Details der Objektorganisation sind in unserem Kontext unwichtig.

    Der Working Tree stellt eine Momentaufnahme eines ausgewählten Knotens dar – in der Regel des letzten, also des jüngsten Knotens einer Branch-Historie. Dieser Knoten wird auch als HEAD des Branches bezeichnet.

    Die ersten Ziele, die wir unter Eclipse erreichen müssen, sind demnach folgende:

    • Aufgabe 1: Erstellen eines lokalen Repositories auf dem PC.
    • Aufgabe 2: Klärung: Wo liegt der “Working Tree”? Welchen Verzeichnisbaum zeigt Eclipse?
    • Aufgabe 3: Einbringen des Inhalts des Projektverzeichnisbaums in den Master-Branch des lokalen Repositories. Initiales Commit.
    • Aufgabe 4: Durchführung von Änderungen im Verzeichnisbaum des Projekts und Testen nachfolgender “Commits”. Blick auf die Git-Versionshistorie auf dem PC. Identifizierung des HEAD-Commmits bzw. -Knotens.

    Zu geeigneten Zeitpunkten möchte ich den aktuellen Stand meiner Dateien auch auf einem zentralen Git-Server (z.B. im Firmen-LAN) bereitstellen. Entsprechende Operation werden als “Push“-Operationen bezeichnet. Ziel (“Target”) eines Pushes ist also ein Branch aus einem anderen (Target-) Repository – hier also im Repository des Servers. Ein Pushvorgang erzeugt dort einen neuen Knoten.

    Andere bzw. auch ich selbst können später vom Server-Repository den dort festgehaltenen Entwicklungsstand auf andere Geräte (z.B. einen Laptop) und dortige lokale Repositories überführen. Dazu führen sie dann sog. Pull- oder Fetch-Operationen durch, mit denen der Versionsstand eines definierten Branches auf dem Server abgefragt und in das lokale Repository überführt und dort integriert wird. Auf den Unterschied zwischen Pull und Fetch gehe ich an passender Stelle in einem späteren Post dieser Serie kurz ein.

    In unserem Szenario “pullen” wir typischerweise den letzten Stand vom Master-Branch des Server-Repositories. Das Target eines Pulls ist also der aktuelle Branch in dem lokalen Repository, von dem aus ich auf ein anderes Repository als Quelle von Veränderungen zugreife. Der Pull erzeugt einen neuen Knoten in meinem lokalen Branch. In unserem Szenario finden Pulls normalerweise auf dem Laptop und später auch auf dem Arbeitsplatz-PC statt. Server-Repositories protokollieren in unserem Szenarion dagegen neue Versionsstände als Ergebnis von Push-Vorgängen zum einem dortigen Branch – bei uns dem Master-Branch des jeweiligen Server-Repositories.

    Sowohl bei einer Push- bzw. Pull-Operationen finden (automatisch) Merge-Prozesse mit dem Stand des betroffenen Branches auf dem Target-Repository statt. In unserem Szenario wird ein erster Push-Prozess also z.B. den Stand einer Datei (oder mehrerer Dateien) des Master-Branches auf einem lokalen PC-Repository mit dem Stand der entsprechenden Datei(en) (bzw. ihrer Objekte) im Master-Branch des Server-Repositorys zusammenführen. Das PC-Repository verändert sich dabei nicht; der neue Knoten entsteht auf dem Server. [Hat man Push/Pull-Vorgänge zwischen definierten Master-Branches unterschiedlicher Repositories verstanden, so sind spätere, komplexere Operationen zwischen anderen lokalen und zentralen Repository-Branches (als den Master-Branches) relativ einfach zu beherrschen.]

    Beim Zusammenführen unterschiedlicher Dateiänderungen in einem Merge können ggf. Konflikte auftreten; diese müssen dann ggf. manuell aufgelöst werden. Das erfordert ggf. detaillierte Vergleiche der in den unterschiedlichen Branches/Repositories vor dem Merge durchgeführten Änderungen. Wir werden aber sehen:

    Arbeitet man als Einzelperson phasenweise entweder ausschließlich auf dem Arbeitsplatz oder in einer anderen Phase ausschließlich auf dem Laptop und gleicht bei einem Übergang zwischen diesen Arbeitsphasen die jeweiligen lokalen Repositories mit einem zentralen Server-Repository in der oben angegebenen Schrittfolge ab, so treten Konflikte in der Regel nicht auf. In diesen Fällen kann Git die notwendigen Merges automatisch und auf einfache Weise erledigen. Man spricht dann auch von Fast-Forward-Merges (FF-Merges).

    Bei FF-Merges sind eigentlich nur neue Knoten in einem Branch zu erzeugen und Referenzen zu bereits bekannten Objekten aufzubauen. Letztere müssen möglicherweise zwischen Repositories kopiert werden; aber echte neue Objekte zu neuen Datenstrukturen sind nicht zu erzeugen. Es liegt dann kein Merge-Commit wie im Falle echter Zusammenführungen mehrer unterschiedlicher Änderungen in den Quell- und Target-Branches vor.

    Die Situation wird in folgender Skizze dargestellt. Wir sehen sukzessiv erstellte Knoten in den Master-Branches dreier Repositories. Echte Commits, bei denen Datenveränderungen vorgenommen wurden, sind als solche bezeichnet und durchnummeriert. Zu jedem Knoten findet man die ersten alphanumerischen Zeichen eines zugehörigen eindeutigen Hashes. In jedem Branch ist der führende Head-Knoten durch eine rote Füllung angedeutet.

    Push und Pull-Aktionen führen in der rein sequentiellen Aktionsabfolge unseres einfachen Szenarios zu unkomplizierten und konfliktfreien FF-Merges, in die wir nicht eingreifen müssen.

    Komplizierter wäre das Mergen allerdings dann, wenn die zentralen Versionsstände zu Dateien, an denen man selbst in seinem lokalen Repository arbeitet, während einer Phase auch durch andere von anderen Stellen aus manipuliert werden würden. Das schließen wir für diese Artikelserie aber mal aus. Etwas schwieriger ist auch ein zwischenzeitlicher lokaler “Reset” auf alte Versionen beim Abgleich zwischen den verschiedenen Arbeitsphasen an unterschiedlichen Geräten zu bewältigen. Auch auch das lassen wir hier zunächst außen vor. Ich komme darauf aber in einem späteren Post der Serie zurück.

    Der eine oder andere wird sich noch die Frage stellen, wie man denn überhaupt zu einem Repository kommt. Unter Git (und damit auch mit entsprechenden Tools unter Eclipse) ist das sowohl über das gezielte Erzeugen und Initialisieren eines Repositories in einem Projekt-Verzeichnis möglich als auch über das Klonen (also Kopieren) von Repositories. Clones mit bestimmten Eigenschaften
    können auch auf Server verschoben und anschließend mit lokalen Repositories verbunden werden. Wir werden uns den Aufbau und das Klonen von Repositories mit Eclipse Tools später genauer ansehen.

    Wir können an dieser Stelle jedoch schon mehrere neue Aufgaben festhalten, die wir unter Eclipse lösen müssen:

    • Aufgabe 5: Erstellen eines zentralen Repositories auf einem Server im LAN. Hierzu werden wir unser lokales PC-Repository aus Aufgabe 1 in einer bestimmten Weise “klonen”. Der Clone wird dann auf dem Server in zugänglicher Weise platziert.
    • Aufgabe 6: Anbinden des zentralen Repositories an das lokale PC-Repository. (Verkopplung der Master-Branches). Klärung der Frage, ob man ein lokales Commit auf dem PC mit einem gleichzeitigen Push zum Server verbinden kann.
    • Aufgabe 7: testweises Überführen von neuen Änderungen, die wir auf dem PC am Projekt vornehmen werden, in den Master-Branch des Git-Server-Repositories.

    Wenden wir uns nun unserem Laptop zu. Im Wunschszenario ist beim Wechsel von einer Arbeitsphase am PC auf eine mobile Phase unter alleinigem Einsatz des Laptops zunächst also eine Push-Operation vom PC auf den Server und danach eine Pull-Operation auf dem Laptop erforderlich. Es ergeben sich also folgende weitere Aufgaben:

    • Aufgabe 8: Erzeugen eines passenden Projektes in einem geeigneten Eclipse-Workspace des Laptops. Klonen des Server-Repositorys und Bereitstellen auf dem Laptop. Verbinden mit dem Projekt. Hier stellt sich u.a. die Frage: Kann man diese Schritte unter Eclipse nicht irgendwie miteinander verbinden?
    • Aufgabe 9: Transfer von neuen Commits, die wir auf dem PC vornehmen, über das zwischengeschaltete Server-Repository in das lokale Repository des Laptops. Also: Commit auf dem PC, Push zum Server und Pull-Operation auf dem Laptop.

    Danach arbeitet man ausschließlich auf dem Laptop weiter:

    • Aufgabe 10: Durchführung von Änderungen und entsprechenden Commits auf dem Laptop. Blick auf die Versionshistorie des Laptops.

    Hinweis: Unter Git wäre prinzipiell auch ein direkter Abgleich zwischen den lokalen Repositories des Laptops und des PCs möglich gewesen. Aus verschiedenen Gründen halten wir aber in einem LAN den Weg über ein zentrales Repository für eine deutlich bessere Idee (Stern-Architektur). Ein Grund besteht etwa in Sicherheitsargumenten und einer Zugriffskontrolle: Nicht jedes System soll auf Verzeichnisstrukturen jedes andere im Netz zugreifen können. Die Zugriffsberechtigung auf bestimmte Repository-Daten lässt sich an zentraler Stelle gleich für mehrere Mitarbeiter steuern. Ein weiterer Grund ist die zentrale Zugriffsprotokollierung. Zudem stehen die Arbeitsergebnisse an zentraler Stelle auch für Backups und andere Mitarbeiter zur Verfügung.

    Betrachten wir die Situation die sich bei der Rückkehr von einer Reise ergibt. Will man dann ausschließlich auf dem Arbeitsplatz-PC weiterarbeiten, so gilt: Erforderlich ist zuerst eine Push-Operation vom Laptop in Richtung Server-Repository des Firmen-LANs und anschließend eine Pull-Operation am PC, bei der man den aktuellen Stand vom Server-Repository in das lokale Repository des PCs überführt.

    Man kann die gesamte Kette “PC => Server => Laptop => Server => PC”, die im Laufe einer Reise abgearbeitet wird, auch an der oben dargestellten Skizze nachvollziehen. Der Weg vom Laptop zum PC ist daher die Umkehrung von Aufgabe 9:

    • Aufgabe 11: Transfer von Änderungen auf dem Laptop über den zentralen LAN-Server auf den Arbeitsplatz-PC.

    Repository im Internet
    Was soll nun in unserem 1-Mann-Szenario der in der Skizze angedeutete weitere Server im Internet ?

    Ein Repository kann man auch als spezielle Backup-Datenbank für erzielte Arbeitsergebnisse betrachten. Zentrale Repositories schützen in diesem Sinne gegen lokale Verluste. Tatsächlich ist es mir schon mal passiert, dass eine Laptop-Platte auf einer Reise ihren Geist aufgegeben hat. Manchmal kann man sich dann sogar eine neue Platte beschaffen – und Linux wie Eclipse sind auch schnell installiert. Aber woher bekommt man in einem solchen Fall ein halbwegs aktuelles Repository? Hier hilft ein Server im Internet.

    Umgekehrt gilt: Auch ein Totalverlust des Laptops (z.B. durch Diebstahl) ist in der Regel weniger schlimm als der Verlust der auf diesem Gerät erzielten Arbeitsergebnisse. D.h., wir werden das Internet-Repository auch während einer Reise relativ regelmäßig mit den auf dem Laptop erzielten Versionsständen per Push-Abgleich versorgen. Soweit wir eben Zugang zu einer halbwegs vernünftigen Internet-Anbindung haben. Da Git inkrementell und komprimiert sichert, ist die Menge der zu transferierenden Daten dann oft gar nicht so groß, wie man meinen möchte. Natürlich gilt, dass man ein zentrales Repository im Internet auch für andere Zwecke wie die Arbeit in einem verteilten Team nutzen könnte.

    Wir benutzen also ein zentrales Git-Repository im Internet (oder mehrere solcher Repositories) als Backup-Instanz. Damit das Repository des Internet-Servers bereits zu Beginn einer Reise ordentlich gefüllt ist, werden wir vom PC aus rechtzeitig entsprechende Push-Aktionen durchführen. Im Sinne einer Backup-Übung sogar relativ regelmäßig. Selbstverständlich müssen unsere Administratoren dafür Sorge tragen, dass der Server und der Kommunikationsweg zum Repository hinreichend gegen Zugriffe anderer geschützt ist. Hier gelten die gleichen Maßnahmen, die man bei jedem anderen Cloud-Service auch treffen würde.

    Es ergeben sich folgende abschließende Aufgaben:

    • Aufgabe 12: Klonen des LAN-Server-Repositories und Verschieben des Clones auf einen Server im Internet. Ankopplung an die Git-Versionsverwaltung unter Eclipse auf dem PC.
    • Aufgabe 13: Testen von gezielten Push-Vorgängen vom PC und vom Laptop zum Repository auf dem Internet-Server. Klärung der Frage, ob wir unter Eclipse mit einem Commit zwei parallel Pushvorgänge zu den verschiedenen Server-Repositories im LAN und im Internet anstoßen können.
    • Aufgabe 14: Testweiser Pull eines per Laptop erzeugten Versionsstandes vom Internet-Repository auf den PC. Anschließend Push vom Laptop zum Repository auf dem LAN-Server (!) und nachfolgender erneuter Pull desselben Versionsstandes durch den PC auch vom LAN-Server. Wird die Identität der Versionsstände erkannt?

    Damit genug der Theorie. Wir haben unser Wunschszenario in Git-Begriffen ausgedeutet und uns dabei ein ordentliches Paket an Aufgaben zusammengestellt, das wir soweit möglich und sinnvoll unter Eclipse abarbeiten wollen. Im nächsten Post dieser Serie
    Erste Schritte mit Git für lokale und zentrale Repositories unter Eclipse – II
    bewegen wir uns dann in die Git-Praxis unter Eclipse und legen dort erstmal ein lokales Repository für unser Beispielprojekt “alien1” an.