From 01794124ae2acb6ac9f2535ad10275348e38ec63 Mon Sep 17 00:00:00 2001 From: Dieter Ziller Date: Wed, 18 Sep 2019 19:22:38 +0200 Subject: [PATCH 1/4] Update client-svn.asc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit client-svn.asc übersetzt --- .../sections/client-svn.asc | 264 +++++++++--------- 1 file changed, 132 insertions(+), 132 deletions(-) diff --git a/book/09-git-and-other-scms/sections/client-svn.asc b/book/09-git-and-other-scms/sections/client-svn.asc index a3e0d87f..9d21a4be 100644 --- a/book/09-git-and-other-scms/sections/client-svn.asc +++ b/book/09-git-and-other-scms/sections/client-svn.asc @@ -1,37 +1,37 @@ [[_git_svn]] -==== Git and Subversion +==== Git und Subversion (((Subversion)))(((Interoperation with other VCSs, Subversion))) -A large fraction of open source development projects and a good number of corporate projects use Subversion to manage their source code. -It's been around for more than a decade, and for most of that time was the _de facto_ VCS choice for open-source projects. -It's also very similar in many ways to CVS, which was the big boy of the source-control world before that. +Ein großer Teil der Open-Source-Entwicklungsprojekte und eine ganze Reihe von Unternehmensprojekten nutzen Subversion zur Verwaltung ihres Quellcodes. +Es gibt Subversion seit mehr als einem Jahrzehnt, und die meiste Zeit war es _erste Wahl_ für ein VCS im Bereich Open-Source-Projekte. +Es ist auch in vielen Aspekten sehr ähnlich zu CVS, das vorher der wichtigste Vertreter der Versionsverwaltung war. (((git commands, svn)))(((git-svn))) -One of Git's great features is a bidirectional bridge to Subversion called `git svn`. -This tool allows you to use Git as a valid client to a Subversion server, so you can use all the local features of Git and then push to a Subversion server as if you were using Subversion locally. -This means you can do local branching and merging, use the staging area, use rebasing and cherry-picking, and so on, while your collaborators continue to work in their dark and ancient ways. -It's a good way to sneak Git into the corporate environment and help your fellow developers become more efficient while you lobby to get the infrastructure changed to support Git fully. -The Subversion bridge is the gateway drug to the DVCS world. +Eines der herausragenden Merkmale von Git ist die bidirektionale Brücke zu Subversion, genannt `git svn`. +Mit diesem Tool können Sie Git als geeigneter Client für einen Subversion-Server verwenden, so dass Sie alle lokalen Funktionen von Git nutzen und dann auf einen Subversion-Server pushen können, als ob Sie Subversion lokal einsetzen würden. +Das bedeutet, dass Sie lokale Branching- und Merging-Aktivitäten vornehmen, die Staging Area nutzen, Rebasing- und Cherry-Picking-Aktivitäten durchführen können, während Ihre Mitstreiter weiterhin in ihrer dunklen und altertümlichen Umgebung tätig sind. +Es ist eine gute Möglichkeit, Git in die Unternehmensumgebung einzuschleusen, Ihren Entwicklerkollegen zu helfen, effizienter zu werden und gleichzeitig die Infrastruktur so zu ändern, um Git vollständig zu unterstützen. +Die Subversion-Brücke ist das Portal zur DVCS-Welt. ===== `git svn` -The base command in Git for all the Subversion bridging commands is `git svn`. -It takes quite a few commands, so we'll show the most common while going through a few simple workflows. +Der Hauptbefehl in Git für sämtliches Subversion-Bridging ist `git svn`. +Es sind ziemlich wenige Befehle erforderlich, so dass wir die gängigsten aufzeigen und dabei einige einfache Workflows durchgehen werden. -It's important to note that when you're using `git svn`, you're interacting with Subversion, which is a system that works very differently from Git. -Although you *can* do local branching and merging, it's generally best to keep your history as linear as possible by rebasing your work, and avoiding doing things like simultaneously interacting with a Git remote repository. +Es ist wichtig zu beachten, dass Sie bei der Verwendung von `git svn` mit Subversion interagieren, einem System, das ganz anders funktioniert als Git. +Obwohl Sie lokales Branching und Merging durchführen *können*, ist es im Allgemeinen ratsam, Ihren Verlauf so linear wie möglich zu gestalten, indem Sie Ihre Arbeiten rebasen. Vermeiden Sie dabei auch die gleichzeitige Interaktion mit einem Git Remote-Repository. -Don't rewrite your history and try to push again, and don't push to a parallel Git repository to collaborate with fellow Git developers at the same time. -Subversion can have only a single linear history, and confusing it is very easy. -If you're working with a team, and some are using SVN and others are using Git, make sure everyone is using the SVN server to collaborate – doing so will make your life easier. +Schreiben Sie Ihren Verlauf nicht um und versuchen Sie nicht, erneut zu pushen. Pushen Sie nicht in ein paralleles Git-Repository, um gleichzeitig mit anderen Git-Entwicklern zusammenzuarbeiten. +Subversion kann nur einen einzigen linearen Verlauf haben und es ist sehr leicht zu verwirren. +Wenn Sie mit einem Team arbeiten und einige verwenden SVN und andere Git, stellen Sie sicher, dass alle den SVN-Server für die gemeinsame Arbeit verwenden – das erleichtert Ihnen den Alltag. -===== Setting Up +===== Einrichtung -To demonstrate this functionality, you need a typical SVN repository that you have write access to. -If you want to copy these examples, you'll have to make a writeable copy of an SVN test repository. -In order to do that easily, you can use a tool called `svnsync` that comes with Subversion. +Um diese Funktionalität zu demonstrieren, benötigen Sie ein typisches SVN-Repository, auf das Sie Schreibzugriff haben. +Wenn Sie die Beispiele kopieren möchten, müssen Sie eine beschreibbare Kopie eines SVN-Test Repository erstellen. +Um das einfach zu realisieren, können Sie das Tool `svnsync` verwenden, das in Subversion enthalten ist. -To follow along, you first need to create a new local Subversion repository: +Um weiter zu machen, müssen Sie zunächst ein neues lokales Subversion-Repository erstellen: [source,console] ---- @@ -39,7 +39,7 @@ $ mkdir /tmp/test-svn $ svnadmin create /tmp/test-svn ---- -Then, enable all users to change revprops – the easy way is to add a `pre-revprop-change` script that always exits 0: +Aktivieren Sie dann alle Benutzer, um revprops zu ändern – der einfachste Weg ist, ein `pre-revprop-change` Skript hinzuzufügen, das immer den exit-Wert 0 hat: [source,console] ---- @@ -49,7 +49,7 @@ exit 0; $ chmod +x /tmp/test-svn/hooks/pre-revprop-change ---- -You can now sync this project to your local machine by calling `svnsync init` with the to and from repositories. +Sie können dieses Projekt nun auf Ihrem lokalen Rechner synchronisieren, indem Sie `svnsync init` mit den Repositorys to und from aufrufen. [source,console] ---- @@ -57,8 +57,8 @@ $ svnsync init file:///tmp/test-svn \ http://your-svn-server.example.org/svn/ ---- -This sets up the properties to run the sync. -You can then clone the code by running +Dadurch werden die Eigenschaften für die Ausführung der Synchronisierung festgelegt. +Sie können den Code dann klonen, indem Sie Folgendes ausführen: [source,console] ---- @@ -71,14 +71,14 @@ Copied properties for revision 2. […] ---- -Although this operation may take only a few minutes, if you try to copy the original repository to another remote repository instead of a local one, the process will take nearly an hour, even though there are fewer than 100 commits. -Subversion has to clone one revision at a time and then push it back into another repository – it's ridiculously inefficient, but it's the only easy way to do this. +Obwohl dieser Vorgang nur wenige Minutenin Anspruch nehmen könnte, dauert der Prozess fast eine Stunde, wenn Sie versuchen, das ursprüngliche Repository in ein anderes Remote-Repository anstelle eines lokalen zu kopieren, obwohl es weniger als 100 Commits gibt. +Subversion muss eine Revision nach der anderen klonen und sie dann wieder in ein anderes Repository verschieben – es ist unvorstellbar ineffizient, aber es ist der einzige einfache Weg, das zu erreichen. -===== Getting Started +===== Erste Schritte -Now that you have a Subversion repository to which you have write access, you can go through a typical workflow. -You'll start with the `git svn clone` command, which imports an entire Subversion repository into a local Git repository. -Remember that if you're importing from a real hosted Subversion repository, you should replace the `file:///tmp/test-svn` here with the URL of your Subversion repository: +Jetzt, da Sie ein Subversion-Repository haben, auf das Sie Schreibrechte haben, können Sie einen typischen Work-Flow absolvieren. +Beginnen Sie mit dem Befehl `git svn clone`, der ein ganzes Subversion-Repository in ein lokales Git-Repository importiert. +Beachten Sie, dass Sie beim Import aus einem echten Subversion-Repository hier `file:///tmp/test-svn` durch die URL Ihres Subversion-Repository ersetzen sollten: [source,console] ---- @@ -100,22 +100,22 @@ Checked out HEAD: file:///tmp/test-svn/trunk r75 ---- -This runs the equivalent of two commands – `git svn init` followed by `git svn fetch` – on the URL you provide. -This can take a while. -If, for example, the test project has only about 75 commits and the codebase isn't that big, Git nevertheless must check out each version, one at a time, and commit it individually. -For a project with hundreds or thousands of commits, this can literally take hours or even days to finish. +Das entspricht zwei Befehlen – `git svn init` gefolgt von `git svn fetch` – auf der von Ihnen angegebenen URL. +Dieser Vorgang kann einige Zeit dauern. +Wenn beispielsweise das Testprojekt nur etwa 75 Commits hat und die Code-Basis nicht so groß ist, muss Git dennoch jede Version einzeln auschecken und einzeln committen. +Bei einem Projekt mit Hunderten oder Tausenden von Commits kann es buchstäblich Stunden oder gar Tage dauern, das zu vollenden. -The `-T trunk -b branches -t tags` part tells Git that this Subversion repository follows the basic branching and tagging conventions. -If you name your trunk, branches, or tags differently, you can change these options. -Because this is so common, you can replace this entire part with `-s`, which means standard layout and implies all those options. -The following command is equivalent: +Der Teil `-T trunk -b branches -t tags` teilt Git mit, dass dieses Subversion-Repository den grundlegenden Branching- und Tagging-Konventionen folgt. +Wenn Sie Ihren Trunk, Ihre Branches oder Tags anders benennen, können sich diese Optionen ändern. +Da dies so häufig vorkommt, können Sie den gesamten Teil durch `-s` ersetzen, was Standardlayout bedeutet und all diese Optionen beinhaltet. +Das folgende Kommando ist dabei gleichwertig: [source,console] ---- $ git svn clone file:///tmp/test-svn -s ---- -At this point, you should have a valid Git repository that has imported your branches and tags: +An dieser Stelle sollten Sie über ein gültiges Git-Repository verfügen, das Ihre Branches und Tags importiert hat: [source,console] ---- @@ -129,9 +129,9 @@ $ git branch -a remotes/origin/trunk ---- -Note how this tool manages Subversion tags as remote refs. +Beachten Sie, dass dieses Tool Subversion-Tags als Remote-Referenzen (engl. refs) verwaltet. (((git commands, show-ref))) -Let's take a closer look with the Git plumbing command `show-ref`: +Werfen wir einen genaueren Blick auf den Git Low-Level-Befehl `show-ref`: [source,console] ---- @@ -145,7 +145,7 @@ a9f074aa89e826d6f9d30808ce5ae3ffe711feda refs/remotes/origin/tags/release-2.0.2r 556a3e1e7ad1fde0a32823fc7e4d046bcfd86dae refs/remotes/origin/trunk ---- -Git doesn't do this when it clones from a Git server; here's what a repository with tags looks like after a fresh clone: +Git macht das nicht, wenn es von einem Git-Server klont, So sieht ein Repository mit Tags nach einem frischen Klon aus: [source,console] ---- @@ -158,12 +158,12 @@ c3dcbe8488c6240392e8a5d7553bbffcb0f94ef0 refs/remotes/origin/master 6dcb09b5b57875f334f61aebed695e2e4193db5e refs/tags/v1.0.0 ---- -Git fetches the tags directly into `refs/tags`, rather than treating them remote branches. +Git fetcht die Tags direkt in `refs/tags`, anstatt sie mit entfernten Branches zu verknüpfen. -===== Committing Back to Subversion +===== Zurück zu Subversion committen -Now that you have a working directory, you can do some work on the project and push your commits back upstream, using Git effectively as an SVN client. -If you edit one of the files and commit it, you have a commit that exists in Git locally that doesn't exist on the Subversion server: +Jetzt, da Sie ein Arbeitsverzeichnis haben, können Sie etwas an dem Projekt arbeiten und Ihre Commits wieder zum Upstream pushen, indem Sie Git als SVN-Client verwenden. +Wenn Sie eine der Dateien bearbeiten und übertragen, haben Sie einen Commit, der in Git lokal existiert aber nicht auf dem Subversion-Server vorhanden ist: [source,console] ---- @@ -172,9 +172,9 @@ $ git commit -am 'Adding git-svn instructions to the README' 1 file changed, 5 insertions(+) ---- -Next, you need to push your change upstream. -Notice how this changes the way you work with Subversion – you can do several commits offline and then push them all at once to the Subversion server. -To push to a Subversion server, you run the `git svn dcommit` command: +Als nächstes müssen Sie Ihre Änderung zum Upstream pushen. +Beachten Sie, wie sich dies auf Ihre Arbeitsweise mit Subversion auswirkt – Sie können mehrere Commits offline durchführen und diese dann alle auf einmal auf den Subversion-Server übertragen. +Um zu einem Subversion-Server zu pushen, führen Sie den Befehl `git svn dcommit` aus: [source,console] ---- @@ -188,10 +188,10 @@ No changes between 4af61fd05045e07598c553167e0f31c84fd6ffe1 and refs/remotes/ori Resetting to the latest refs/remotes/origin/trunk ---- -This takes all the commits you've made on top of the Subversion server code, does a Subversion commit for each, and then rewrites your local Git commit to include a unique identifier. -This is important because it means that all the SHA-1 checksums for your commits change. -Partly for this reason, working with Git-based remote versions of your projects concurrently with a Subversion server isn't a good idea. -If you look at the last commit, you can see the new `git-svn-id` that was added: +Dabei werden alle Commits ausgeführt, die Sie oberhalb des Subversion Server-Codes gemacht haben, dafür jeweils einen eigenen Subversion-Commit und dann Ihren lokaler Git-Commit umgeschrieben, um einen eindeutigen Identifier einzufügen. +Das ist wichtig, weil es bedeutet, dass sich alle SHA-1-Prüfsummen für Ihre Commits ändern. +Aus diesem Grund ist es keine gute Idee, gleichzeitig mit Git-basierten Remotes Ihrer Projekte und einem Subversion-Server zu arbeiten. +Wenn Sie sich den letzten Commit ansehen, sehen Sie die neu hinzugefügte `git-svn-id`: [source,console] ---- @@ -205,14 +205,14 @@ Date: Thu Jul 24 03:08:36 2014 +0000 git-svn-id: file:///tmp/test-svn/trunk@77 0b684db3-b064-4277-89d1-21af03df0a68 ---- -Notice that the SHA-1 checksum that originally started with `4af61fd` when you committed now begins with `95e0222`. -If you want to push to both a Git server and a Subversion server, you have to push (`dcommit`) to the Subversion server first, because that action changes your commit data. +Es ist zu beachten, dass die SHA-1-Prüfsumme, die ursprünglich mit `4af61fd` begann, als Sie die Daten übertragen haben, nun mit `95e0222` beginnt. +Wenn Sie sowohl auf einen Git-Server als auch auf einen Subversion-Server pushen möchten, müssen Sie zuerst auf den Subversion-Server pushen (`dcommit`), da diese Aktion Ihre Commit-Daten ändert. -===== Pulling in New Changes +===== Neue Änderungen pullen -If you're working with other developers, then at some point one of you will push, and then the other one will try to push a change that conflicts. -That change will be rejected until you merge in their work. -In `git svn`, it looks like this: +Wenn Sie mit anderen Entwicklern zusammenarbeiten, dann wird irgendwann einer von Ihnen pushen, und andere versuchen, eine Änderung voranzutreiben, die Konflikte verursacht. +Diese Änderung wird abgelehnt, bis Sie deren Arbeit mergen. +In `git svn` sieht das so aus: [source,console] ---- @@ -229,7 +229,7 @@ ones (if any) seem to be successfully integrated into the working tree. Please see the above messages for details. ---- -To resolve this situation, you can run `git svn rebase`, which pulls down any changes on the server that you don't have yet and rebases any work you have on top of what is on the server: +Um diese Situation zu lösen, können Sie die `git svn rebase` ausführen, das alle Änderungen auf dem Server, die Sie noch nicht haben, pullt und alle ihre lokalen Arbeiten an die Spitze zum Server neu überträgt (engl. rebase): [source,console] ---- @@ -251,7 +251,7 @@ ones (if any) seem to be successfully integrated into the working tree. Please see the above messages for details. ---- -Now, all your work is on top of what is on the Subversion server, so you can successfully `dcommit`: +Jetzt ist Ihre gesamte Arbeit an der Spitze des Subversion-Servers, so dass Sie `dcommit` erfolgreich einsetzen können: [source,console] ---- @@ -265,8 +265,8 @@ No changes between 5762f56732a958d6cfda681b661d2a239cc53ef5 and refs/remotes/ori Resetting to the latest refs/remotes/origin/trunk ---- -Note that unlike Git, which requires you to merge upstream work you don't yet have locally before you can push, `git svn` makes you do that only if the changes conflict (much like how Subversion works). -If someone else pushes a change to one file and then you push a change to another file, your `dcommit` will work fine: +Im Unterschied zu Git, das voraussetzt, dass Sie Upstream-Arbeiten, die Sie noch nicht lokal haben, zuerst mergen, bevor Sie pushen können, zwingt Sie `git svn` dazu nur dann, wenn die Änderungen im Konflikt stehen (ähnlich wie bei Subversion). +Wenn jemand anderes eine Änderung an einer Datei vorantreibt und Sie eine Änderung an einer anderen Datei vorantreiben, funktioniert Ihr `dcommit` gut: [source,console] ---- @@ -283,12 +283,12 @@ W: a0253d06732169107aa020390d9fefd2b1d92806 and refs/remotes/origin/trunk differ First, rewinding head to replay your work on top of it... ---- -This is important to remember, because the outcome is a project state that didn't exist on either of your computers when you pushed. -If the changes are incompatible but don't conflict, you may get issues that are difficult to diagnose. -This is different than using a Git server – in Git, you can fully test the state on your client system before publishing it, whereas in SVN, you can't ever be certain that the states immediately before commit and after commit are identical. +Es ist sehr wichtig, sich daran zu halten, denn das Ergebnis ist ein Projektstatus, der beim Push auf keinem Ihrer Computer vorhanden war. +Wenn die Änderungen inkompatibel sind, aber keine Konflikte verursachen, können Probleme auftreten, die schwer zu diagnostizieren sind. +Das ist ein Unterschied gegenüber der Nutzung eines Git-Servers – in Git können Sie den Zustand auf Ihrem Client-System vor der Veröffentlichung vollständig testen, während Sie in SVN nie sicher sein können, dass die Zustände unmittelbar vor dem Commit und nach dem Commit identisch sind. -You should also run this command to pull in changes from the Subversion server, even if you're not ready to commit yourself. -You can run `git svn fetch` to grab the new data, but `git svn rebase` does the fetch and then updates your local commits. +Sie sollten diesen Befehl auch ausführen, um Änderungen vom Subversion-Server einzubinden, auch wenn Sie nicht bereit sind, selbst zu committen. +Es ist ratsam, `git svn fetch` auszuführen, um die neuen Daten zu holen, aber `git svn rebase` übernimmt den Fetch und aktualisiert dann Ihre lokalen Commits. [source,console] ---- @@ -299,18 +299,18 @@ First, rewinding head to replay your work on top of it... Fast-forwarded master to refs/remotes/origin/trunk. ---- -Running `git svn rebase` every once in a while makes sure your code is always up to date. -You need to be sure your working directory is clean when you run this, though. -If you have local changes, you must either stash your work or temporarily commit it before running `git svn rebase` – otherwise, the command will stop if it sees that the rebase will result in a merge conflict. +Wenn Sie ab und zu git svn rebase laufen lassen, stellen Sie sicher, dass Ihr Code immer auf dem neuesten Stand ist. +Sie sollten jedoch überprüfen, ob Ihr Arbeitsverzeichnis sauber ist, wenn Sie diese Funktion auslösen. +Wenn Sie lokale Änderungen haben, müssen Sie Ihre Arbeit entweder verstecken (engl. stash) oder temporär committen, bevor Sie `git svn rebase` ausführen – andernfalls wird der Befehl angehalten, wenn er erkennt, dass das Rebase zu einem Merge-Konflikt führen wird. -===== Git Branching Issues +===== Git Branching Probleme -When you've become comfortable with a Git workflow, you'll likely create topic branches, do work on them, and then merge them in. -If you're pushing to a Subversion server via `git svn`, you may want to rebase your work onto a single branch each time instead of merging branches together. -The reason to prefer rebasing is that Subversion has a linear history and doesn't deal with merges like Git does, so `git svn` follows only the first parent when converting the snapshots into Subversion commits. +Sobald Sie sich mit einem Git-Workflow vertraut gemacht haben, werden Sie wahrscheinlich Topic-Branches erstellen, an ihnen arbeiten und sie dann verschmelzen (mergen). +Wenn Sie über `git svn` auf einen Subversion-Server pushen, können Sie Ihre Arbeit jedes Mal auf einen einzigen Branch rebasieren, anstatt Branches zu mergen. +Die Begründung für ein Rebasing ist, dass Subversion eine lineare Historie hat und sich nicht wie Git mit Merges beschäftigt. So folgt `git svn` bei der Konvertierung der Snapshots in Subversion Commits nur dem ersten Elternteil. -Suppose your history looks like the following: you created an `experiment` branch, did two commits, and then merged them back into `master`. -When you `dcommit`, you see output like this: +Nehmen wir an, Ihr Verlauf sieht wie folgt aus: Sie haben einen `experiment` Branch erstellt, zwei Commits durchgeführt und diese dann wieder mit dem `master` zusammengeführt. +Wenn Sie `dcommit` aufrufen, erscheint folgende Anzeige: [source,console] ---- @@ -330,18 +330,18 @@ No changes between 71af502c214ba13123992338569f4669877f55fd and refs/remotes/ori Resetting to the latest refs/remotes/origin/trunk ---- -Running `dcommit` on a branch with merged history works fine, except that when you look at your Git project history, it hasn't rewritten either of the commits you made on the `experiment` branch – instead, all those changes appear in the SVN version of the single merge commit. +Das Ausführen von `dcommit` auf einem Branch mit zusammengeführtem Verlauf funktioniert gut, außer wenn Sie sich Ihre Git-Projekt-Historie ansehen, er hat keinen der Commits, die Sie auf dem `experiment` Branch gemacht haben, neu geschrieben – statt dessen erscheinen alle diese Änderungen in der SVN-Version eines einzelnen Merge-Commits. -When someone else clones that work, all they see is the merge commit with all the work squashed into it, as though you ran `git merge --squash`; they don't see the commit data about where it came from or when it was committed. +Wenn jemand anderes diese Arbeit klont, sieht man nur den Merge-Commit mit der gesamten Arbeit, die in ihn hineingedrückt wurde, als ob Sie `git merge --squash` ausgeführt hätten; man sieht die Commit-Daten nicht, woher sie stammen oder wann sie committed wurden. ===== Subversion Branching -Branching in Subversion isn't the same as branching in Git; if you can avoid using it much, that's probably best. -However, you can create and commit to branches in Subversion using `git svn`. +Branching in Subversion ist nicht dasselbe wie Branching in Git. Es ist wahrscheinlich das Beste, wenn Sie es so oft vermeiden wie möglich. +Sie können aber mit `git svn` in Subversion Branches anlegen und dorthin committen. ===== Creating a New SVN Branch -To create a new branch in Subversion, you run `git svn branch [new-branch]`: +Um einen neuen Branch in Subversion zu erstellen, führen Sie `git svn branch [new-branch]` aus: [source,console] ---- @@ -354,39 +354,39 @@ Successfully followed parent r91 = f1b64a3855d3c8dd84ee0ef10fa89d27f1584302 (refs/remotes/origin/opera) ---- -This does the equivalent of the `svn copy trunk branches/opera` command in Subversion and operates on the Subversion server. -It's important to note that it doesn't check you out into that branch; if you commit at this point, that commit will go to `trunk` on the server, not `opera`. +Dadurch wird das Äquivalent des Befehls `svn copy trunk branches/opera` in Subversion ausgeführt und auf dem Subversion-Server angewendet. +Wichtig dabei ist, dass er Sie nicht in diesen Branch auscheckt; wenn Sie an dieser Stelle committen, wird dieser Commit in den `trunk` auf dem Server gehen, nicht in at this point, that commit will go to `trunk` on the server, not `opera`. -===== Switching Active Branches +===== Aktive Branches wechseln -Git figures out what branch your dcommits go to by looking for the tip of any of your Subversion branches in your history – you should have only one, and it should be the last one with a `git-svn-id` in your current branch history. +Git findet heraus, in welchen Branch Ihre dcommits gehen, indem es nach der Spitze eines Ihrer Subversion Branches in Ihrem Verlauf sucht – Sie sollten nur einen haben, und es sollte der Letzte sein, der eine `git-svn-id` in Ihrem aktuellen Branchverlauf hat. -If you want to work on more than one branch simultaneously, you can set up local branches to `dcommit` to specific Subversion branches by starting them at the imported Subversion commit for that branch. -If you want an `opera` branch that you can work on separately, you can run +Falls Sie an mehr als einem Branch gleichzeitig arbeiten möchten, können Sie lokale Branches einrichten, um `dcommit` auf bestimmte Subversion Branches zu beschränken, indem Sie diese beim importierten Subversion Commit für diesen Branch starten. +Einen `opera` Branch, in dem Sie separat bearbeiten können, können Sie starten mit: [source,console] ---- $ git branch opera remotes/origin/opera ---- -Now, if you want to merge your `opera` branch into `trunk` (your `master` branch), you can do so with a normal `git merge`. -But you need to provide a descriptive commit message (via `-m`), or the merge will say ``Merge branch opera'' instead of something useful. +Um Ihren `opera` Branch in `trunk` (Ihren `master` Branch) zu mergen, können Sie das mit einem normalen `git merge` machen. +Aber Sie sollten unbedingt eine beschreibende Commit-Meldung (via `-m`) angeben, sonst wird beim Merge anstelle von etwas Vernünftigem „Merge branch opera“ angezeigt. -Remember that although you're using `git merge` to do this operation, and the merge likely will be much easier than it would be in Subversion (because Git will automatically detect the appropriate merge base for you), this isn't a normal Git merge commit. -You have to push this data back to a Subversion server that can't handle a commit that tracks more than one parent; so, after you push it up, it will look like a single commit that squashed in all the work of another branch under a single commit. -After you merge one branch into another, you can't easily go back and continue working on that branch, as you normally can in Git. -The `dcommit` command that you run erases any information that says what branch was merged in, so subsequent merge-base calculations will be wrong – the `dcommit` makes your `git merge` result look like you ran `git merge --squash`. -Unfortunately, there's no good way to avoid this situation – Subversion can't store this information, so you'll always be crippled by its limitations while you're using it as your server. -To avoid issues, you should delete the local branch (in this case, `opera`) after you merge it into trunk. +Obwohl Sie für diese Operation `git merge` verwenden und der Merge wahrscheinlich viel einfacher ist als in Subversion (da Git automatisch die entsprechende Merge-Basis für Sie erkennt), ist es kein normaler Git Merge-Commit. +Sie müssen diese Daten an einen Subversion-Server zurück pushen, der keinen Commit mit mehr als einem Elternteil verarbeiten kann; nachdem Sie ihn zum Server gepusht haben, sieht er also aus wie ein einzelner Commit, der die gesamte Arbeit eines anderen Branchs unter einem einzigen Commit zusammenfasst. +Nachdem Sie einen Branch in einem anderen zusammengeführt haben, können Sie nicht einfach zurückgehen und an diesem Branch weiterarbeiten, wie Sie es normalerweise in Git tun. +Das `dcommit` Kommando, das Sie ausführen, löscht alle Informationen, die zeigen, in welchen Branch zusammengeführt wurde, so dass nachfolgende Berechnungen der Merge-Basis falsch sind – `dcommit` lässt Ihr `git merge` Ergebnis aussehen, als ob Sie `git merge --squash` ausgeführt hätten. +Leider gibt es keine gute Methode, diese Situation zu vermeiden - Subversion kann diese Informationen nicht speichern, daher werden Sie immer von den Einschränkungen des Systems behindert, während Sie es als Ihren Server verwenden. +Um Fehler zu vermeiden, sollten Sie den lokalen Branch (in diesem Fall `opera`) löschen, nachdem Sie ihn in `trunk` eingefügt haben. -===== Subversion Commands +===== Subversion Kommandos -The `git svn` toolset provides a number of commands to help ease the transition to Git by providing some functionality that's similar to what you had in Subversion. -Here are a few commands that give you what Subversion used to. +Das `git svn` Toolset bietet eine Reihe von Befehlen, die den Übergang zu Git erleichtern, indem es einige Funktionen bereitstellt, die denen ähneln, die Sie von Subversion aus kennen. +Wir haben hier ein paar Befehle, mit denen Sie das bekommen, was Subversion vorher konnte. -====== SVN Style History +====== Verlauf im SVN-Format -If you're used to Subversion and want to see your history in SVN output style, you can run `git svn log` to view your commit history in SVN formatting: +Wenn Sie an Subversion gewöhnt sind und Ihren Verlauf im SVN-Stil sehen möchten, können Sie `git svn log` ausführen, um Ihren Commit-Verlauf in SVN-Formatierung anzuzeigen: [source,console] ---- @@ -407,16 +407,16 @@ r85 | schacon | 2014-05-02 16:00:09 -0700 (Sat, 02 May 2014) | 2 lines updated the changelog ---- -You should know two important things about `git svn log`. -First, it works offline, unlike the real `svn log` command, which asks the Subversion server for the data. -Second, it only shows you commits that have been committed up to the Subversion server. -Local Git commits that you haven't dcommited don't show up; neither do commits that people have made to the Subversion server in the meantime. -It's more like the last known state of the commits on the Subversion server. +Sie sollten zwei wichtige Dinge über `git svn log` wissen. +Erstens funktioniert es offline, im Unterschied zum echten `svn log` Befehl, der den Subversion-Server nach den Daten fragt. +Zweitens zeigt es Ihnen nur Commits an, die zum Subversion-Server übertragen wurden. +Lokale Git-Commits, die Sie noch nicht mit `dcommit` bestätigt haben, werden nicht angezeigt; ebenso wenig wie Commits, die von Leuten in der Zwischenzeit auf dem Subversion-Server gemacht wurden. +Es ist mehr wie der letzte bekannte Zustand der Commits auf dem Subversion-Server. -====== SVN Annotation +====== SVN Anmerkung -Much as the `git svn log` command simulates the `svn log` command offline, you can get the equivalent of `svn annotate` by running `git svn blame [FILE]`. -The output looks like this: +So wie der Befehl `git svn log` den Befehl `svn log` offline simuliert, können Sie das Äquivalent von `svn annotate` abrufen, indem Sie `git svn blame [FILE]` ausführen. +Die Ausgabe sieht wie folgt aus: [source,console] ---- @@ -435,11 +435,11 @@ $ git svn blame README.txt 2 temporal ---- -Again, it doesn't show commits that you did locally in Git or that have been pushed to Subversion in the meantime. +Noch einmal, zur Wiederholung! Auch hier werden keine Commits angezeigt, die Sie lokal in Git gemacht haben oder die in der Zwischenzeit in Subversion verschoben wurden. -====== SVN Server Information +====== SVN Server-Information -You can also get the same sort of information that `svn info` gives you by running `git svn info`: +Wenn Sie `git svn info` ausführen, können Sie die gleiche Art von Informationen erhalten, die Ihnen `svn info` liefert: [source,console] ---- @@ -456,35 +456,35 @@ Last Changed Rev: 87 Last Changed Date: 2009-05-02 16:07:37 -0700 (Sat, 02 May 2009) ---- -This is like `blame` and `log` in that it runs offline and is up to date only as of the last time you communicated with the Subversion server. +Das ist wie bei `blame` und `log`, denn es läuft offline und ist nur ab der letzten Kommunikation mit dem Subversion-Server auf dem neuesten Stand. -====== Ignoring What Subversion Ignores +====== Ignorieren, was Subversion ignoriert -If you clone a Subversion repository that has `svn:ignore` properties set anywhere, you'll likely want to set corresponding `.gitignore` files so you don't accidentally commit files that you shouldn't. -`git svn` has two commands to help with this issue. -The first is `git svn create-ignore`, which automatically creates corresponding `.gitignore` files for you so your next commit can include them. +Wenn Sie ein Subversion-Repository klonen, in dem irgendwo `svn:ignore` Eigenschaften gesetzt sind, werden Sie wahrscheinlich entsprechende `.gitignore` Dateien setzen wollen, damit Sie nicht versehentlich Dateien übertragen, die Sie nicht sollten. +`git svn` verfügt über zwei Befehle, um bei diesem Problem zu helfen. +Der Erste ist `git svn create-ignore`, der automatisch entsprechende `.gitignore` Dateien für Sie erstellt, damit sie bei Ihrem nächsten Commit berücksichtigt werden. -The second command is `git svn show-ignore`, which prints to stdout the lines you need to put in a `.gitignore` file so you can redirect the output into your project exclude file: +Der zweite Befehl ist `git svn show-ignore`, der die Zeilen nach stdout ausgibt, die Sie in eine `.gitignore` Datei einfügen müssen, damit Sie die Ausgabe in die Ausschlussdatei Ihres Projekts umleiten können: [source,console] ---- $ git svn show-ignore > .git/info/exclude ---- -That way, you don't litter the project with `.gitignore` files. -This is a good option if you're the only Git user on a Subversion team, and your teammates don't want `.gitignore` files in the project. +Auf diese Weise überhäufen Sie das Projekt nicht mit `.gitignore` Dateien. +Das ist eine gute Option, wenn Sie der einzige Git-Benutzer in einem Subversion-Team sind und Ihre Teamkollegen keine `.gitignore` Dateien im Projekt haben wollen. -===== Git-Svn Summary +===== git svn Zusammenfassung -The `git svn` tools are useful if you're stuck with a Subversion server, or are otherwise in a development environment that necessitates running a Subversion server. -You should consider it crippled Git, however, or you'll hit issues in translation that may confuse you and your collaborators. -To stay out of trouble, try to follow these guidelines: +Die `git svn` Tools sind nützlich, wenn Sie mit dem Subversion-Server feststecken oder sich anderweitig in einer Entwicklungsumgebung befinden, die den Betrieb eines Subversion-Servers erfordert. +Sie sollten es jedoch als verkümmertes Git betrachten, oder Sie werden Probleme in der Umsetzung haben, die Sie und Ihre Mitwirkenden verwirren könnten. +Um keine Schwierigkeiten zu bekommen, versuchen Sie sich an diese Hinweise zu halten: -* Keep a linear Git history that doesn't contain merge commits made by `git merge`. - Rebase any work you do outside of your mainline branch back onto it; don't merge it in. -* Don't set up and collaborate on a separate Git server. - Possibly have one to speed up clones for new developers, but don't push anything to it that doesn't have a `git-svn-id` entry. - You may even want to add a `pre-receive` hook that checks each commit message for a `git-svn-id` and rejects pushes that contain commits without it. +* Führen Sie einen linearen Git-Verlauf, der keine Merge-Commits von `git merge` enthält. + Rebasieren Sie alle Arbeiten, die Sie außerhalb Ihres Haupt-Branchs durchführen, wieder in diesen ein; mergen Sie sie nicht. +* Richten Sie keinen separaten Git-Server ein und arbeiten Sie nicht mit einem zusammen. +Möglicherweise haben Sie einen, um Klone für neue Entwickler zu starten, aber pushen Sie nichts, was nicht über einen `git-svn-id` Eintrag verfügt. +Sie können eventuell einen `pre-receive` Hook hinzufügen, der jede Commit-Nachricht auf einen `git-svn-id` überprüft und Pushes, die Commits ohne ihn enthalten, ablehnt. -If you follow those guidelines, working with a Subversion server can be more bearable. -However, if it's possible to move to a real Git server, doing so can gain your team a lot more. +Wenn Sie diese Leitlinien befolgen, kann die Arbeit mit einem Subversion-Server leichter umsetzbar sein. +Mit einem Umstieg auf einen echten Git-Server kann Ihr Team erheblich mehr an Effizienz gewinnen. From 276493331ea8ac812823f1e9392a70a65a75e0fb Mon Sep 17 00:00:00 2001 From: Dieter Ziller Date: Wed, 18 Sep 2019 21:26:22 +0200 Subject: [PATCH 2/4] Update status.json --- status.json | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/status.json b/status.json index bae0aef6..efce3496 100644 --- a/status.json +++ b/status.json @@ -84,7 +84,7 @@ "sections/policy.asc": 0 }, "09-git-and-other-scms": { - "1-git-and-other-scms.asc": 0, + "1-git-and-other-scms.asc": 100, "sections/client-hg.asc": 0, "sections/client-p4.asc": 0, "sections/client-svn.asc": 0, From 47a67841a2bfec5351864adf92a124944c0264b4 Mon Sep 17 00:00:00 2001 From: Dieter Ziller Date: Wed, 18 Sep 2019 21:26:55 +0200 Subject: [PATCH 3/4] Revert "Update status.json" This reverts commit 276493331ea8ac812823f1e9392a70a65a75e0fb. --- status.json | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/status.json b/status.json index efce3496..bae0aef6 100644 --- a/status.json +++ b/status.json @@ -84,7 +84,7 @@ "sections/policy.asc": 0 }, "09-git-and-other-scms": { - "1-git-and-other-scms.asc": 100, + "1-git-and-other-scms.asc": 0, "sections/client-hg.asc": 0, "sections/client-p4.asc": 0, "sections/client-svn.asc": 0, From 3015e69a0730a3676cf9f3def9aa2b98ed1077eb Mon Sep 17 00:00:00 2001 From: Dieter Ziller Date: Wed, 18 Sep 2019 21:28:19 +0200 Subject: [PATCH 4/4] Update status.json --- status.json | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/status.json b/status.json index bae0aef6..929cc473 100644 --- a/status.json +++ b/status.json @@ -84,10 +84,10 @@ "sections/policy.asc": 0 }, "09-git-and-other-scms": { - "1-git-and-other-scms.asc": 0, + "1-git-and-other-scms.asc": 100, "sections/client-hg.asc": 0, "sections/client-p4.asc": 0, - "sections/client-svn.asc": 0, + "sections/client-svn.asc": 100, "sections/client-tfs.asc": 0, "sections/import-custom.asc": 0, "sections/import-hg.asc": 0,