[D2G] Aufbau der D2G-Repositories about deploy-to-grading HOT 8 CLOSED

@AKirsch1 Gibt es signifikate Vorteile, wenn jeder Task in einem eigenen Repo lebt (also bei "SampleSolution")?

Ich habe den Maintenance-Aspekt und das Erstellen neuer Aufgaben im Blick. Da finde ich ein zentrales Repo deutlich angenehmer (also "HomeworkSolution"), weil ich da alles an einer Stelle habe und die zentrale Konfig auch nur einmal machen muss und mit einem git subtree push (oder filter-tree) den passenden Unterordner für die Studis "rausschieben" kann.

Die "SampleSolution" hat für mich zudem den Nachteil, dass ich bei einer Überarbeitung der Vorgaben (Schnittstellen, Tests) diese erstmal "blind" im Vorgaberepo ("Template") bearbeiten würde, dann meine SampleSolution rebasen würde und schauen würde, ob alles passt. (Sicher kriegt man das auch noch besser hin mit Hilfsbranches im SampleSolution und Cherry-Pick und so, aber trotzdem ist das gefühlt ein recht aufwändiger Stunt.)

from deploy-to-grading.

Gibt es signifikate Vorteile, wenn jeder Task in einem eigenen Repo lebt (also bei "SampleSolution")?

Ich bin mir nicht sicher, ob ich das richtig verstehe, weil in "SampleSolution" eigentlich die Lösungen für alle Tasks drin sein sollen. Ansonsten hätte ich doch Unmengen an Repositories.

Da finde ich ein zentrales Repo deutlich angenehmer (also "HomeworkSolution"), weil ich da alles an einer Stelle habe und die zentrale Konfig auch nur einmal machen muss und mit einem git subtree push (oder filter-tree) den passenden Unterordner für die Studis "rausschieben" kann.

Das wäre das, was ich bei "SampleSolution" einfacher finde. Du brauchst weder ein git subtree push noch musst du bei der Config eine Unterscheidung zwischen Studi-Lösungen und Beispiellösungen machen.

Die "SampleSolution" hat für mich zudem den Nachteil, dass ich bei einer Überarbeitung der Vorgaben (Schnittstellen, Tests) diese erstmal "blind" im Vorgaberepo ("Template") bearbeiten würde [...]

Hier gebe ich dir recht. Das ist für mich der einzige große Nachteil, den ich momentan bei der Variante sehe.

Ich denke aber auch, dass man recht schnell zwischen den Varianten wechseln kann. Die "SampleSolution"-Variante braucht, wenn ich keinen Denkfehler habe, keine Anpassung des D2A: Wenn es in den "StudiSolution"s klappt, dann funktioniert auch "SampleSolution". Und auf der anderen Seite haben wir einen fertigen PR für die "HomeworkSolution"-Variante, bei dem nur noch wenige Anpassungen notwendig sein sollten. Also so viel Aufwand sollte es nicht sein, dass man beides mal ausprobieren kann, wenn alles steht.

from deploy-to-grading.

Gibt es signifikate Vorteile, wenn jeder Task in einem eigenen Repo lebt (also bei "SampleSolution")?
Ich bin mir nicht sicher, ob ich das richtig verstehe, weil in "SampleSolution" eigentlich die Lösungen für alle Tasks drin sein sollen. Ansonsten hätte ich doch Unmengen an Repositories.

Ja, okay, da habe ich Dich scheinbar falsch verstanden. Ich hatte mitgenommen, dass bei der Variante "SampleSolution" pro Task ein eigenes Repo angelegt wird.

from deploy-to-grading.

Ich denke aber auch, dass man recht schnell zwischen den Varianten wechseln kann. Die "SampleSolution"-Variante braucht, wenn ich keinen Denkfehler habe, keine Anpassung des D2A: Wenn es in den "StudiSolution"s klappt, dann funktioniert auch "SampleSolution". Und auf der anderen Seite haben wir einen fertigen PR für die "HomeworkSolution"-Variante, bei dem nur noch wenige Anpassungen notwendig sein sollten. Also so viel Aufwand sollte es nicht sein, dass man beides mal ausprobieren kann, wenn alles steht.

Bin grad nicht sicher, ob ich Dir folgen kann. In der einen Variante habe ich ein zentrales Repo mit dem Vorgabecode und den Lösungen, aus dem ich am Anfang des Semesters Ordner für die Studis rauslöse. In der anderen Variante habe ich ein Repo mit dem Vorgabecode und ein zweites mit den Lösungen.

In der zweiten Variante arbeite ich also genau wie die Studis. Das hat den Vorteil, dass ich alles aus deren Sicht erlebe. Der Nachteil ist aber, dass ich bei der Pflege der Vorgaben einen ziemlichen Aufriss machen muss - zumindest habe ich bisher keine "einfache" Lösung. Es läuft immer auf "Zauber" mit komplexeren Branches oder Kopieren von Code o.ä. hinaus. Wenn Du hier mit einer halbwegs einfachen und stabilen Vorgehensweise um die Ecke kommst, bin ich sofort dabei :)

from deploy-to-grading.

In der einen Variante habe ich ein zentrales Repo mit dem Vorgabecode und den Lösungen, aus dem ich am Anfang des Semesters Ordner für die Studis rauslöse. In der anderen Variante habe ich ein Repo mit dem Vorgabecode und ein zweites mit den Lösungen.

Genau so ist es von mir gedacht. Das mit dem "Rauslösen" wäre aber in beiden Varianten der Fall bzw. möglich (Das Tasks-Repo habe ich in der Tabelle ja als optional markiert).

Wenn Du hier mit einer halbwegs einfachen und stabilen Vorgehensweise um die Ecke kommst, bin ich sofort dabei :)

Bisher habe ich noch keine Lösung dafür, aber ich werde mal schauen, ob ich da was finde.

from deploy-to-grading.

Wenn Du hier mit einer halbwegs einfachen und stabilen Vorgehensweise um die Ecke kommst, bin ich sofort dabei :)

Eine alternative Lösung könnten Git Worktrees sein. Damit könnten wir uns sozusagen nur temporär während der Erstellung/Überarbeitung die Ordnerstruktur erstellen, wie wir sie mit HomeworkSolution permanent hätten. Damit würden wir die Aufgabenstellung und die Lösung auf unterschiedlichen Branches erstellen. Den Aufgabenstellungs-Branch müssten wir dann in das darüberliegende Repo mergen.

Um das umzusetzen bräuchten wir wahrscheinlich ein paar zusätzliche Skripte, damit man sich nicht immer manuell Worktrees erstellen muss. Aber ich habe noch nicht ausprobiert, ob es so, wie ich es denke, ohne Probleme funktionieren würde.

@cagix Sind meine Überlegungen logisch und hast du schon Erfahrungen mit worktrees?

Wenn das Quatsch ist, würde ich dieses Issue schließen und die Variante mit HomeworkSolutions umsetzen.

from deploy-to-grading.

git worktree ist ja eigentlich nur ein in einem zweiten ordner ausgecheckter branch. das klappt echt gut, für die ide ist das einfach ein weiteres projekt.

aber es ist halt nur ein (weiterer) branch im repo, der dann auch auf github landen würde (ok, vielleicht in einem zweiten remote?). wie würde das helfen im obigen szenario?

from deploy-to-grading.

Mein Gedanke war, dass im einen Branch (dem worktree-Subordner) die Vorgabe (vergleichbar mit "vorgabe"-Ordner in HomeworkSolution) liegt und im "Main"-Branch die Lösung (vergleichbar mit "loesungs"-Ordner in HomeworkSolution). Mir fällt nur gerade auf, dass es problematisch wird, wenn ich Aufgaben überarbeiten will. Nach dem Fork-Gedanken liegt auch die Vorgabe im Lösungsordner, wodurch sie beim Überarbeiten doppelt vorhanden wäre.

Wahrscheinlich ist es deswegen sinnvoller, beim HomeworkSolution-Repository zu bleiben und das Issue hier zu schließen.

from deploy-to-grading.