Du kannst auch den Inhalt des Patches als Patch bezeichnen, und den Inhalt in den Code übernehmen.

Schon allein um den Arbeitsablauf zu vereinfachen wird man das tunlichst tun. Die Linux-Kernel-Sources die ich beziehe sind immer integrale Dateien, und nichts, was ich hinterher noch patche.

Ein Patch als separat vertriebener Codeschnipsel kommt m.W. nur upstream vor, wenn ich dem Entwickler das, was ich am Code geändert habe, als Patch zusende (bei mir auf dem Rechner entwickle ich den Patch ja auch nicht als separate Einheit, sondern generiere den Patch aus einem korrigierten Code mittels diff), oder wenn der Entwickler mit Zugang zu den Repos nicht oder träge reagiert - dann verbreitet sich schonmal der Patch als eigene Einheit.

Also willst du im Prinzip sagen, das jeglicher Quelltext nur aus Patches besteht, da er ja niemals in einem Rutsch programmiert wurde?

Es ist doch aber nur Sinnvoll etwas als Patch zu bezeichnen, das auch extra geliefert und angewandt werden muss, oder? Ansonsten ist es für mich ein ganz normaler Beitrag zum Projekt, bzw nur solange ein Patch, bis es eingepflegt wurde.

hi,

bestimmte patches werden auch zurückportiert, was man oft eben bei Kernelversionen sieht, die ansonsten in der vorliegenden Version nicht weiterentwickelt werden? Da sich das Hauptaugenmerk auf die aktuelle Nachfolgerversion bezieht? Es gibt also einen Unterschied zum diff? Der Patch wird verwoben/integriert. Solange er nicht upstream (also im Projekt) eingepflegt ist, ist es ein Provisorium.

stfischr schrieb:

Also willst du im Prinzip sagen, das jeglicher Quelltext nur aus Patches besteht, da er ja niemals in einem Rutsch programmiert wurde?

Nein. Du fidest bei mir auch keinen Hinweis auf "in einem Rutsch" aus dem Du das ableiten kannst.

Angenommen ich habe einen Sortieralgorithmus der prima funktioniert, wenn eine gerade Anzahl Elemente sortiert wird, und bei einer ungeraden nicht, und nun schickt mir jemand einen Patch, in dem statt

1

 n.size / 2

dann

1

 (n.size + 1) / 2

steht, und ich übernehme die Zeile, ob nun mittels des Werkzeuges "patch" oder manuell, und selbst wenn ich das aus kruden Gründen in

1

 (1 + n.size) / 2

ändere - es flickt den Fehler und kann somit als Flicken bezeichnet werden.

Wenn ich Programme schreibe entwickeln sich diese aber nicht aus einem reinen Flickenteppich. Auch können neue Features dazukommen oder ein das Programm kann einem Redesign unterzogen werden.

Es ist doch aber nur Sinnvoll etwas als Patch zu bezeichnen, das auch extra geliefert und angewandt werden muss, oder?

Wenn ich selbst einen Fehler finde und behebe nenne ich das auch einen Patch (den ich geschrieben habe), der aber nicht geliefert wird.

Ansonsten ist es für mich ein ganz normaler Beitrag zum Projekt, bzw nur solange ein Patch, bis es eingepflegt wurde.

Was wurde eingeflegt? Der Patch. Nun ist das Programm gepatcht. Der Patch ist im Programm drin, oder hat jmd. die falsche Version, die ohne Patch, aus der Versionsverwaltung gewählt?

L.A.S. schrieb:

hi,

bestimmte patches werden auch zurückportiert, was man oft eben bei Kernelversionen sieht, die ansonsten in der vorliegenden Version nicht weiterentwickelt werden?

Was ist die Frage?

Da sich das Hauptaugenmerk auf die aktuelle Nachfolgerversion bezieht?

Dieser Satz kein, geschweige Frage?

Es gibt also einen Unterschied zum diff?

Glaubst Du das nicht?

Der Patch wird verwoben/integriert. Solange er nicht upstream (also im Projekt) eingepflegt ist, ist es ein Provisorium.

Wieso fehlt hier das Fragezeichen?

user unknown schrieb:

stfischr schrieb:

Also willst du im Prinzip sagen, das jeglicher Quelltext nur aus Patches besteht, da er ja niemals in einem Rutsch programmiert wurde?

Nein. Du fidest bei mir auch keinen Hinweis auf "in einem Rutsch" aus dem Du das ableiten kannst.

Naja, die Tatsache, das du jede Korrektur als Patch bezeichnet, auch wenn sie niemals extra ausgeliefert wird, lässt keinen anderen Schluss zu.

Angenommen ich habe einen Sortieralgorithmus der prima funktioniert ...

1	n.size / 2

dann

1	(n.size + 1) / 2

... es flickt den Fehler und kann somit als Flicken bezeichnet werden.

Jupp, es ist aber nichtmehr als Patch erkennbar, wenn du das Programm so auslieferst. Niemand wird beim lesen des Quelltextes sagen "Oh die ( + 1) sieht ja aus wie nachträglich reingepatcht". Und man muss als Anwender auch nix besonderes machen, man muss speziell gesagt nix patchen.

http://de.wikipedia.org/wiki/Patch_%28Software%29 gibt mir da auch recht, das ein Patch immer eine extra Datei ist, die nur kleine Änderungen am Programm/Quelltext vornimmt und alleine garnicht lauffähig ist.

stfischr schrieb:

user unknown schrieb:

stfischr schrieb:

Also willst du im Prinzip sagen, das jeglicher Quelltext nur aus Patches besteht, da er ja niemals in einem Rutsch programmiert wurde?

Nein. Du fidest bei mir auch keinen Hinweis auf "in einem Rutsch" aus dem Du das ableiten kannst.

Naja, die Tatsache, das du jede Korrektur als Patch bezeichnet, auch wenn sie niemals extra ausgeliefert wird, lässt keinen anderen Schluss zu.

Doch, habe ich doch gerade erklärt. Wenn ich eine neue Funktionalität in mein Programm einbaue - sagen wir, der Videoplayer kann jetzt auch Filme rückwärts abspielen. Wieso sollte ich das als Patch bezeichnen?

Mit Ausliefern hat es gleich gar nichts zu tun. Wieso sollte ich einen Patch extra ausliefern?

Angenommen ich sitze am Rechner und streite mich mit uneinsichtigen Mitmenschen um Kaisers Bart - nur mal angenommen - und dann macht mein Mailprogramm "Bing" und ich sehe nach, und ein Patch liegt im Posteingang samt Fehlerbeschreibung, netten Wünschen und so weiter.

Dann schaue ich mir den Fehlerbericht samt Patch an, stelle fest, dass Susi Sorgsam aus dem Senegal Recht hat, und übernehme den Patch - vielleicht durch Anwenden des Programms "Patch", vielleicht mit cut'n'paste, vielleicht in dem ich es nachtippe.

Ins Changelog übernehme ich eine kl. Notiz, und den Versionszähler zähle ich eins hoch und packe wieder alles hübsch als bz2 und lade es hoch mit einer Notiz, was geändert wurde.

Natürlich nenne ich dies einen Patch - wie sonst? Mir wurde ein Patch geschickt und ich habe ihn übernommen. Jetzt enthält meine Software den Patch.

Angenommen ich habe einen Sortieralgorithmus der prima funktioniert ...

1	n.size / 2

dann

1	(n.size + 1) / 2

... es flickt den Fehler und kann somit als Flicken bezeichnet werden.

Jupp, es ist aber nichtmehr als Patch erkennbar, wenn du das Programm so auslieferst. Niemand wird beim lesen des Quelltextes sagen "Oh die ( + 1) sieht ja aus wie nachträglich reingepatcht". Und man muss als Anwender auch nix besonderes machen, man muss speziell gesagt nix patchen.

http://de.wikipedia.org/wiki/Patch_%28Software%29 gibt mir da auch recht, das ein Patch immer eine extra Datei ist, die nur kleine Änderungen am Programm/Quelltext vornimmt und alleine garnicht lauffähig ist.

Das ist ein Strohmannargument, das unterstellt ich hätte gegenteiliges behauptet, was aber falsch ist. Nie habe ich behauptet ein Patch sei alleine lauffähig - mir ist völlig unklar wie Du auf so eine Idee kommen kannst.

Die Größe ist allerdings nicht vorgegeben; es kann auch große Patches geben.

Es spielt auch keine Rolle ob jmd. beim Lesen des Quellcodes erkennen kann, dass eine Korrektur nachträglich vorgenommen wurde.

Hier gibt es einen kleinen Einblick in die Verwendung des Begriffs bei Heise: http://www.heise.de/open/artikel/Kernel-Log-Was-3-5-bringt-1-Netzwerk-1624233.html?artikelseite=2

Als kleine, separate Datei existiert der Patch nur, und auch das nicht zwingend, als übermittelte Einheit. Derjenige, der den Patch schreibt (oder bestreitet Ihr, dass man einen Patch schreiben kann) schreibt diesen ja nicht als diff-Fitzelchen, sondern flickt das Programm als eine Quellcodedatei, und verschickt, nachdem er mit diff die Veränderung isoliert hat, aus Effizienzgründen nur den geänderten Part.

Die vielfältige Verwendung des Begriffs 'patch' im Zusammenhang mit Software kann in den Linuxkernelquellen gut studiert werden; zur Eröffnung werfe ich ein:

/usr/src/linux/Documentation/00-INDEX: - procedure to get a source patch included into the kernel tree.

in die Diskussion.

Eure Behauptung ist in etwa so als würde man sagen, dass ein Medikament nur das ist, was in der Packung beim Apotheker liegt - sobald ich es aber auf den Löffel gebe oder im Mund habe sei es kein Medikament mehr, oder wenn es in meinem Magen, in der Blutbahn ist.

Auch wenn der Patch nicht mehr isoliert erkennbar ist, so ist er dennoch in die Software eingegangen, und ich kann nach 10 Jahren noch auf die 2 Zeilen zeigen die mir einst Susi aus dem Senegal sandte, und sagen:

"Hier ist übrigens der Patch von Susi, von dem damals so viel die Rede war!"

"Wo?"

"Na hier, Zeile 58 und 59."

Man sieht natürlich keine Nahtstellen, weil Software keine Nähte hat.

user unknown schrieb:

Auch wenn der Patch nicht mehr isoliert erkennbar ist, so ist er dennoch in die Software eingegangen, und ich kann nach 10 Jahren noch auf die 2 Zeilen zeigen die mir einst Susi aus dem Senegal sandte, und sagen:

"Hier ist übrigens der Patch von Susi, von dem damals so viel die Rede war!"

"Wo?"

"Na hier, Zeile 58 und 59."

Man sieht natürlich keine Nahtstellen, weil Software keine Nähte hat.

Das stimmt natürlich. Dann habe ich die Bedeutung wohl bisher immer falsch interpretiert und Patch explizit mit einer extra Datei verbunden. Um jetzt nicht eine riesige Metaiskussion loszutreten (ok schon geschehen) einigen wir uns als auf die Übersetzung "Flicken"?

PS:

Angenommen ich sitze am Rechner und streite mich mit uneinsichtigen Mitmenschen um Kaisers Bart - nur mal angenommen

als Streit hätte ich das nicht bezeichnet. Solange man Argumente bringt und nicht beleidigt ist das bei mir ne Diskussion.

Auf "Flicken" einige ich mich gerne mit Dir.

als Streit hätte ich das nicht bezeichnet. Solange man Argumente bringt und nicht beleidigt ist das bei mir ne Diskussion.

Na ein Glück haben wir ein neues Streitthema gefunden.

Man kann sich um ein Grundstück streiten, um das größere Förmchen im Sand, um das richtige Betriebssystem, die Vorfahrt und um Kaisers Bart.

Mit und ohne Argumente; der Streit kann auch mit körperlichen Mitteln geführt werden. Was ein Streitthema ist, und was ein Argument, das kann natürlich selbst wieder strittig sein. Eine Diskussion ist es natürlich trotzdem, und Diskussion setzt, so man nicht ironisch wird, zivilisierte Umgangsformen vorraus.

Eine spezielle, institutionalisierte Form des Streits ist der Rechtsstreit. Da trifft man sich zum Streiten vor Gericht, und hat hoffentlich auch Argumente dabei.

Nun gut, aber das ist jetzt wirklich total ot.

Was ist mit den Begriffen

Quoting und Wildcards?

Maskieren und Jokerzeichen. Maskieren sicher nicht bei allen Umständen, aber bei typischen.

Jokerzeichen für Wildcards? Da wird auch der Teufel mit Beelzebub ausgetrieben.

"Meta-Zeichen werden auch Wildcards, Joker-Zeichen oder Platzhalter genannt."

Quelle: http://www.schatenseite.de/unixshell.html

Hi,

ich sehe das so wie der Rote Ritter. Wenn es bei bestimmten Begriffen sinnvolle Übersetzungen gibt, sollte man sich für andere aber nicht welche aus den Fingern ziehen. Sinn machen imho Ausdrücke wie "Working directory" (Arbeitsverzeichnis) oder Mountpunkt (Einhängepunkt), die so auch gebräuchlich verwendet werden. Für "Wildcards" kenne ich keine andere gebräuchliche Verwendung. Und die Fachbegriffe sollten nicht so weit entstellt werden, dass Leute, die ausschließlich die Fachbegriffe kennen, die zerdeutschten Bezeichnungen nicht verstehen.

Dieser Artikel ist auch als Richtlinie zu sehen und nicht als feste Regel.

Gruss Lasall