Re: Kurzversion aus Snapshot.dq m. Snapx.Exe

2004-06-29 Diskussionsfäden Michael Heydekamp
Martin Wodrich [EMAIL PROTECTED] wrote on 27.06.04:

 Michael Heydekamp schrieb am 27.06.04 um 18:01:

 Schon mal ganz hilfreich, danke.  Aber wie kann man erkennen, was
 nur in die v3.40, was nur in die v3.20 und was in beide Versionen
 committet wurde?
 Am Anfang eines jedes Logeintrags gibt es eine große Liste mit
 symbolischen Namen.
 Ja, hab' ich gesehen, aber:
 Diese sollten einem dabei helfen, die anschließend folgenen
 Commitlogs richtig zuzuordnen.

 Eher nicht.  Reply-To-All ist z.B. definitiv nicht in der v3.2x
 vorhanden, trotzdem tauchen vor dem CVS-Log symbolische Namen der
   ^^^ ^
 v3.2x auf:

 --8--
 symbolic names:
 [...]
 Branch_3_20_Release: 1.5.0.2
 RC0_3_20: 1.5
 Beta_3_20_21: 1.5
 Beta_3_20_20: 1.4
 Beta_3_20_19: 1.3
 [...]
 
 revision 1.13.2.5
 date: 2001-04-28 15:47:29 +;  author: sv;  state: Exp;  lines:
 +24 -1 - Reply-To-All :-) (Reply to sender and *all* recipients of a
message simultaneously, except to own and marked
addresses. 'Reply-To-Marked' also possible.
Automatically activated with P, Ctrl-P and
Shift-P if not disabled in Config and if more
than one reply address available after removal of
dupes and invalid addresses. ZConnect and RFC
  only.)
 --8--

 Wo siehst du da eine Resision der 3.2x ?

Ich hab' gar nicht von Revisionen gesprochen, sondern nur von den
symbolischen Namen, die Du erwähntest.  Ich hatte es so verstanden, als
wäre das Auftauchen eines solchen alleine schon ein Hinweis darauf, daß
an der Version etwas geändert worden sein könnte.

 1.13 ist höher als 1.5.x.x . 1.5er Resionen oder niedriger sind 3.2x
 er Revisonen bei dieser Datei.

Ok.  Trotzdem ist das IMO nicht ganz leicht nachzuvollziehen, denn die
Rev. 1.13.2.5, um die es bei obigem Commit geht, taucht wiederum bei den
symbolic names - logischerweise - gar nicht auf.

Sollte man auf jeden Fall mit dem Log in der Unit nochmal abgleichen.


Michael

FreeXP Entwickler-Mailingliste
[EMAIL PROTECTED]
http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list


Re: CVS daily diff

2004-06-29 Diskussionsfäden Michael Heydekamp
Joachim Merkel [EMAIL PROTECTED] wrote on 28.06.04:

 Michael Heydekamp ([EMAIL PROTECTED]) schrieb:

 Außerdem stehen immer lange Diskussionen an, wenn Features erklärt
 werden. Manche solcher Diskussionen werden nie beendet.. Ich will
 keine nutzlosen Diskussionen, daher wundere ich mich, daß der CVS
 schlicht und einfach unter Wert genutzt wird.

 Den Zusammenhang zwischen CVS und langen Diskussionen über Features
 (welche genau meinst Du?) verstehe ich jetzt nicht.  Bzw. inwiefern
 diese Diskussionen vermieden würden, und warum sie vermieden werden
 sollten.

 Gerade hast Du noch geschrieben, daß viele Sachen von Dir nicht
 commitet werden, die nicht ausreichend dokumentiert sind.

Nah - wo hast Du das denn gelesen?  Nicht die Dokumentation ist
unvollständig und lückenhaft, sondern der Code selbst.  Würde es nur an
ein paar erläuternden Zeilen für SNAPSHOT.TXT fehlen, hätte ich die
längst geschrieben und das Zeug wäre im CVS.

 Das heißt IMO, selbst wenn sie es wären, stünde Dir noch eine
 Diskussion bevor.

Vielleicht ja, vielleicht nicht.  Aber das ist doch völlig unabhängig
davon, wie lange sich die Entwicklung jeweils hingezogen hat.

Wenn jemand in der Lage wäre, das ganze Gerümpel in einem Tag
fertigzustellen und zu dokumentieren, würde er es also am Ende des Tages
committen.  Es würde sich aber danach exakt derselbe Diskussionsbedarf
(der auch null sein kann) ergeben.

Ich wüßte auch nicht, was es z.B. daran zu diskutieren gäbe, wenn man
den Bug behebt, daß Cc-Mails oder X-Postings unter bestimmten
Bedingungen immer noch in mehrere Einzelnachrichten auseinander-
dividiert werden.  Da freut und bedankt man sich (oder nimmt
kommentarlos zur Kenntnis), daß das jetzt nicht mehr so ist und gut ist.

Da, wo Diskussionsbedarf von vorneherein gegeben und erkennbar ist (z.B.
bei Designfragen), habe ich es auch in der Vergangenheit schon so
gehalten, daß ich die Diskussion selbst anstoße.

 Entweder wird man also vermeiden über diskutieren zu wollen, auch weil
 es nicht ausreichend dokumentiert ist

Der Fall wird - wie schon bisher - nicht eintreten.  Es wird (mehr als)
ausreichend dokumentiert sein.

 oder aber auch bei mir gibt es z.B. Workarounds, wo fertige Lösungen
 noch nicht ausdiskutiert werden können. Ich habe einige Änderungen für
 das verbesserte Handling zum Verschieben und nachträglichen Bearbeiten
 von Brettnachrichten und vermutlich komme ich auf über ein halbes
 Dutzend solcher Änderungen die nicht bis zu Ende programmiert sind.

Na eben, und die sehe ich auch nicht und will sie auch gar nicht sehen,
solange Du sie nicht selbst als bis zu Ende programmiert betrachtest -
es sei denn, man wird um Hilfe bei konkreten Problemen gebeten, weil
derjenige irgendwo festhängt.

Letzteres ist aber gar nicht mein Problem, sondern hier geht es um ein
reines Zeitproblem, nämlich das Mißverhältnis zwischen dem aufgrund der
Komplexität der Änderungen und der Menge der anstehenden Arbeiten
insgesamt zwingend notwendigen Zeitaufwand und der zur Verfügung
stehenden Zeit.

Falls Deine nicht zu Ende programmierten Workarounds von vorneherein
darauf angelegt sind, eine Art Temp-Fixes für eigene Zwecke zu sein, ist
das allerdings etwas anderes und nicht mit den Änderungen vergleichbar,
über die ich spreche und an denen ich arbeite.

 Wenn es jemand übernehmen will, von mir aus. Ich wundere mich einfach
 nur, daß es nach Jahren CVS keinen Bedarf an solchen Zwischenstufen
 gibt, sondern die Sachen stur bis zu Ende entwickelt werden.

Es würde mich noch mehr Zeit kosten, a) die Sachen in regelmäßigen
Abständen aufdröseln zu müssen, um sie überhaupt sinnvoll und für Dritte
nachvollziehbar committen zu können, und b) an Diskussionen über Lücken
und Bugs teilnehmen zu müssen, die ich eh schon kenne und an denen ich
noch arbeite.

Der Code muß ein bestimmtes Stadium erreicht haben, um überhaupt eine
sinnvolle Diskussion führen zu können, und das hat er nach meinen
Maßstäben noch nicht.

Zumindest möchte ich den Code soweit bereinigt haben und wieder
durchblicken, daß ich an einer etwaigen Diskussion darüber auch
teilnehmen kann. ;)

 Wobei ich durchaus nachvollziehen kann, daß eine Grenze gesetzt wird,
 die im konkreten Fall für eine Version definiert werden soll.

Gut, aber dann verstehe ich das hier nicht:

 Wenn man keine Einblicke in seine Werkstatt gibt, wird man auch
 keinen dazu motivieren mitzumachen.

Nehmen wir an, Du arbeitest z.B. an dem Verschieben von Nachrichten in
andere Bretter.  Da wäre es mir viel lieber, Du wartest am Tag X mit
einer funktionierenden Lösung auf, statt über einen längeren Zeitraum
halbfertiges Zeug zu committen, das nur teilweise funktioniert und mit
dem ich mich eh nicht näher beschäftigen kann.

Vor allem wüßte ich überhaupt nicht, weshalb es mich weniger motivieren
sollte, meine eigene Arbeit in einem völlig anderen Bereich
fertigzustellen, nur weil ich Dir bei Deiner Arbeit nicht ständig über
die Schulter gucken konnte.

Und auch hier nochmal das Beispiel: Bei dem