Obsługuje urządzenia JclUnitVersioning
, co naraża stałych, takich jak te w bardziej spójny sposób:
{$IFDEF UNITVERSIONING}
const
UnitVersioning: TUnitVersionInfo = (
RCSfile: '$URL: https://jcl.svn.sourceforge.net/svnroot/jcl/tags/JCL-1.101- Build2725/jcl/source/common/Jcl8087.pas $';
Revision: '$Revision: 1$';
Date: '$Date: 12/05/2008 10:29:10$';
LogPath: 'JCL\source\common'
);
{$ENDIF UNITVERSIONING}
Stara wersja jednostki JclUnitVersioning
jest tutaj] 1 i daje ogólne pojęcie, jak to działa: jednostka ma globalny numer function GetUnitVersioning: TUnitVersioning;
, który przekazuje informacje o wersji dla wszystkich jednostek obsługujących UNITVERSIONING.
Stamtąd można je wyliczyć i zapytać o szczegóły.
Jest to bardzo przydatne na przykład wtedy, gdy chcesz wiedzieć, która dokładna wersja urządzenia jest połączona z Twoim .EXE.
--jeroen
Załóżmy na przykład, że wysyłasz wersję aplikacji do klienta i przesyła on raporty o błędach. Być może chciałbyś wiedzieć, jaka wersja JCL-SubcomponentX lub MyCustomComponents-Y była zaangażowana w tę statycznie połączoną kompilację twojego końcowego produktu (twojej dużej aplikacji). –
To wygląda niezwykle pomocne. Jeśli to rozumiem, mógłbyś mieć funkcję zgłaszania wersji jednostki (jeśli jest obecna) każdej jednostki w danej aplikacji? Włączenie gałęzi źródłowej ... Ułatwiłoby wykrycie problemów scalania. –
Dokładnie. Mogę mieć na przykład pięć dużych aplikacji, z których wszystkie mają wspólną warstwę DB. Może chciałbym wiedzieć, że UberWare 3.2 jest dostarczany z DB Layerem 2.1, ale MegaSoft 2.4, miał tylko DB Layer 2.0. Problem rozwiązany. Dla każdego, kto o tym nie wiedział, tagi RCS powyżej są automatycznie aktualizowane podczas checkin time, nie tylko przez RCS i CVS, ale także przez inne systemy kontroli wersji, takie jak subversion. –