[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Suche Tool: Aenderungen im Unterverzeichnis protokollieren
[Thread Prev] | [Thread Next]
- Subject: Re: Suche Tool: Aenderungen im Unterverzeichnis protokollieren
- From: Raphael Becker <rabe@xxxxxxxxx>
- Date: Mon, 20 Jul 2009 15:04:33 +0200
- To: uugrn@xxxxxxxxxxxxxxx
Hi Alexander, On Mon, Jul 20, 2009 at 01:25:45PM +0200, Alexander Holler wrote: > >In die inode-Tabelle passen alle Werte ausser Datei- und > >Verzeichnisnamen. 2 Dateinamen als Hardlink auf den gleichen inode haben > >AFAIK immer den gleichen timestamp, die gleichen Attribute, die gleichen > >Checksummen, uid/gid/permissions, ... > > Damit landest du irgendwann bei den Aufgaben die ein SCM (source code > managment) fuer dich uebernimmt. Kurzanleitung fuer git: /usr/ports ist nur *ein* Spezialfall und ich habe das da auch nicht primaer auf die Sourcen abgesehen sondern auf die Packages, die ich daraus erstelle und (dort) ablege. Die Packages laufen nicht syncron zu den Ports sondern werden zB woechentlich neu gebaut und dann als Ganzes aktualisiert. Deswegen ist es ziemlich sinnlos, hier die Aenderungen vom Upstream zu tracken. Mein primaeres Ziel ist, anhand von vorher/nachher einen Ueberblick darueber zu geben, welche Neuigkeiten es im Repository gibt. Man koennte jetzt *exakt* fuer *diesen* Zweck eine spezielle Loesung aus einem Guss entwickeln oder aber das Problem als mehrere aufeinander aufbauende Teilloesungen zu implementieren. Ich sehe hier 2-3 Funktionen: a) regelmaessig Informationen einsammeln, aufbereiten, normalisieren und vorhalten (Datenquelle erzeugen, cron job) Das habe ich in meinem Vorposting dargestellt (gfind ... ) b) Einfache Abfragen auf diese Datenquelle absetzen und daraus Historien, Neuigkeiten, Statistiken, ... erstellen ("Reporting") c) Diese (tabellarisch) aufbereiteten Daten in verschiedene Formaten weiter verarbeiten, etwa als RSS, Mail-Notify, Visualisierungen oder allgemein als Trigger. Die Datenquelle (aus b) ist relativ universell nutzbar, wenn es gescheite Schnittstellen dafuer gibt. Das *muss* *nicht* SQL sein, koennte aber. Gruss Raphael -- Raphael Becker <rabe@xxxxxxxxx> http://rabe.uugrn.org/ https://www.xing.com/profile/Raphael_Becker GnuPG: E7B2 1D66 3AF2 EDC7 9828 6D7A 9CDA 3E7B 10CA 9F2D .........|.........|.........|.........|.........|.........|.........|.. -- http://mailman.uugrn.org/mailman/listinfo/uugrn Wiki: http://wiki.uugrn.org/wiki/UUGRN:Mailingliste Archiv: http://lists.uugrn.org/