Re: Dokumentmanagement

On Fri, 22 Aug 2014 09:50:02 +1000 (EST), Peter Ross wrote:
> Ich glaube, ich habe mich nicht deutlich genug ausgedrueckt.
>
> Heute sind die "Terminals" Windows-7-Rechner (ca. 50) und die Leute davor
> mit allerlei Berufserfahrung, aber kaum im Bereich
> Computertechnik/Softwareentwicklung und mit RCS/CVS/subversion/git und
> Branches etc. voellig ueberfordert.

Das hätte ich auch nicht anders angenommen. :-)

> Oft wollen die nur das Excel-Spreadsheet vom letzten Montag wiederfinden -

Und da wäre jetzt meine Frage: Wenn sich das Dokument seit letzten
Montag nicht geändert hat? Ein relativer Verweis müßte dann für
die Tage, an denen das Dokument "gleichgeblieben" ist, auf ein
und dieselbe Datei verweisen. Eine neue "Instanz" wird immer nur
dann angelegt, wenn sich die Datei ändert. Und wie Du schon
angemerkt hast: Das muß automatisch geschehen.

> hassen es aber auch, wenn man aus Versehen mit dem Dokument ohne die
> letzten Aenderungen arbeiotet (weil jemand ProjektPlan.xls angefasst hat
> und dann als ProjektPlanErneuert.xls abgespeichert hat)

Hier ist "gut gemeint" wieder das Gegenteil von "gut gemacht".
Ein automatisiertes System, bei dem Nutzer "per Datenbank" ein
Dokument zur Herausgabe abfragen und es dann wieder "einschicken"
müssen, wäre vielleicht günstiger. Lokale Kopien oder umbenannte
Dateien spielen dann keine Rolle mehr. Eine flankierende erziehe-
rische Maßnahme wäre das Löschen von Benutzerdateien... ;-)

Eine Art Datenbankunterbau, auch wenn sie auf Basis des Dateisystems
implementiert und mit Symlinks und Skripten realisiert wird, scheint
möglich zu sein, ein "echtes" Dokumentenmanagementsystem wäre aber
wohl die Lösung, die man "üblicherweise von extern" einkauft, die
Kosten kann man eh auf die Kunden umlegen.

> [die Rechner-Version von "Wer Ordnung haelt, ist zu faul zum Suchen"]

Nein, die Rechner-Version von "Ich weiß das besser als der gesunde
Menschenverstand!", also offer.doc, offer_final.doc, offer_final_2.doc,
copy_of_offer.doc, new_copy_of_offer_1.doc - tja, welches Angebot
schicken wir denn mal raus? :-)

> (Desweiteren ist oft kein Vertrauen in zentrales Backup da, "ich mach mein
> Backup lieber selbst" und dann verheddert der Betreffende sich spaeter mit
> der Kopie der Kopie..)

Die o. g. Lernhilfe korrigiert diesen Irrglauben schon nach wenigen
Tagen. Man kann immer damit argumentieren: "Wenn hier jeder macht,
was er will, dann können wir gleich alle nach Hause gehen!" ;-)

> Mein Plan 9 ist im Moment, diese zu klonen und als
> /shares/archive/Tuesday/Marketing zu mounten.
>
> Es ist aber schwierig, die vorletzte Version von
> /shares/Marketing/cauliflower/harvest/routine.doc zu finden.
>
> Ist da etwa
> /shares/archive/Tuesday/Marketing/cauliflower/harvest/routine.doc
> oder /shares/archive/Friday/Marketing/cauliflower/harvest/routine.doc?
>
> Ein Symlink als /shares/Marketing/cauliflower/harvest/routine.doc;-1 waere
> schoener (also in place)
>
> (oder, da Windows am Ende, vielleicht
> /shares/Marketing/cauliflower/harvest/archive/1/routine.doc)

Genau das ist eben die Fragestellung: Sollte man eventuell auf
die oben diskutierte "Dokumentendatenbank" eine Art Kalender
oben aufpappen, der zeigt, wann welcher Versionsstand einer
Datei entstanden ist? Also so schön was webbaisertes, wo der
Nutzer dann im Kalender anklicken kann? Ein typischer Vorgang
wäre dann aber "runterladen" / "hochladen", was wieder die
Arbeitsergonomie stört. Wenn Du die Versionsauswahl aber in
den Datei-öffnen-Dialog legen willst, mußt Du alles auf
Dateisystemebene abbilden. Das kann auch dynamisch sein,
z. B. mal an den Haaren herbeigezogen:

/shares/Marketing/cauliflower/harvest/current/routine.doc
/shares/Marketing/cauliflower/harvest/archive/yesterday/routine.doc
/shares/Marketing/cauliflower/harvest/archive/1/routine.doc
/shares/Marketing/cauliflower/harvest/archive/2/routine.doc
/shares/Marketing/cauliflower/harvest/archive/3/routine.doc

Hier ist die Zählweise aber "umgekehrt", d. h. die kleinste
Zahl gibt die nächste Vorversion an, und es muß bei einer
Änderung "aufgerückt" werden (3->4, 2->3, 1->2, current->1,
neue Datei in current/ ist die gerade geänderte Datei). Das
"Denkproblem" ist hier: Wieviele Tage ist es her? Wenn der
Nutzer also die Datei von Montag haben will, muß er überlegen,
der wievielte Vortag das ist. Oder es werden täglich neue
Symlinks gesetzt für die aktuelle Woche.

yesterday -> /shares/Marketing/cauliflower/harvest/archive/1/routine.doc
Thu -> /shares/Marketing/cauliflower/harvest/archive/1/routine.doc
Wed -> /shares/Marketing/cauliflower/harvest/archive/2/routine.doc
Tue -> /shares/Marketing/cauliflower/harvest/archive/3/routine.doc

Und was wäre mit der Vorwoche? Dann müßte man einen ganzen
Kalender mit Symlinks zusammenstricken. Das wäre dann auch
wiederum praktisch, wenn jemand sagt, "Ich will die Version
vom 11.8.2014, da war der Kunde mit dem Angebot einverstanden."

> Das koennte vermutlich ein Cronjob sein, der auf diff oder zfs diff
> aufbaut und dann diese Symlinks anlegt.

Ja, aber dann hast Du es eben mit kompletten Dateisystemen zu
tun, also üblicherweise "voll aufgefüllten" Unterbäumen, die Du
dann als Share bereitstellst.

> Ich weiss aber nicht, ob das praktikabel ist oder schlicht und ergreifend
> zum Zusammenbruch des Servers fuehrt, wenn ich das im Arbeitsalltag mache.

Und letztlich muß es ja auch noch idioten-, äh anwendersicher sein,
d. h. versehentlich die falsche Datei zu erwischen soll vermieden
werden. Wenn man die o. g. Idee mit der Webbasiertheit auf die
Spitze treibt, läßt man die Nutzer schön in einem "Web-Office"
arbeiten und speichert (und versioniert) alles zentral. Ein Diff
zeigt an, ob es nötig ist (z. B. Datei geöffnet und ausgedruckt
heißt: keine neue Version anlegen; Datei geöffnet und geändert
heißt: neue Version anlegen + aktuelle Version = diese Version).

Das riecht verdächtig nach Aufgabe für eine Eigenentwicklung,
fürchte ich. Ein _einfaches_, auf Dateisystemebene arbeitendes
Tool ist mir jedenfalls nicht bekannt. Und je mehr ich darüber
nachdenke, desto fälscher klingt das, was ich vorschlage oder
zumindest als Denkbrocken niederschreibe... :-)

> Andere Ideen?

Tausende. Nur nicht direkt zu diesem Thema. :-)

-- 
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message