2011-03-09 13 views

Odpowiedz

7

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

+0

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). –

+0

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. –

+1

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. –

Powiązane problemy