Actualizarea configurațiilor atipice sau cum se elimină plictisirea //
Voi începe, probabil, cu modul în care am învățat să actualizez configurațiile non-tipice și de ce m-au făcut toate astea.
Am început să actualizez k de la momentul tc 77.
Mecanismul de actualizare în 7-ke a fost foarte simplu. Creăm 3 baze. 1 - baza de lucru, a doua copie a bazei de lucru, a treia - baza de date eșantion de aceeași eliberare.
Îl comparăm cu o nouă versiune. Al doilea, cu o eliberare tipică. 3yu cu o nouă versiune.
Total în fereastra 2 de comparație vedem toate "îmbunătățirile" din cea de-a treia văd toate modificările din lansare. și, în principal, să decidem ceea ce părăsim și ceea ce luăm de la noua versiune.
După actualizare, verificarea: baza de date actualizată și actualizată este comparată cu o versiune tipică. Lista modificărilor trebuie să fie identică cu a doua bază de date. Dacă da, atunci actualizarea se face corect.
În 8ke, totul sa schimbat radical.
Începând cu faptul că într-o singură bază de date se stochează 3 sau mai multe configurații.
1 - Configurare de bază - Acea cu care programatorul funcționează direct.
2 - Configurarea bazei de date - Aceasta este configurația pe care rulează în prezent baza de date. (adică dacă ați scris câteva linii în configurator, aceasta înseamnă că în prima configurația de bază și configurarea bazei de date nu au devenit identice, în al doilea)
3 - Configurația furnizorului este, în esență, o lansare de eșantion.
4 .. configurațiile furnizorilor pot fi multe, dar acest subiect este un articol complet diferit.
Acest fapt a permis dezvoltatorilor într-o singură bază de date să implementeze o grămadă de bunătăți. Mai specific despre ei:
Punctul 1. - Când faceți upgrade într-o singură bază de date, puteți vedea toate cele 3 diferențe dintre cele 3 baze 77 menționate mai sus. (Diferența dintre baza de date eșantion din noua versiune, "Îmbunătățiri ale programatorilor" - diferențele dintre configurația de bază și configurația furnizorului și diferența dintre configurația de bază și noua versiune).
punctul 2. - Teoretic, pot apărea 3 cazuri în timpul actualizării
1 caz - obiectul a fost modificat numai în baza de date, iar în versiune nu au existat modificări la acest obiect
2 caz - obiectul este modificat numai în versiune, iar în baza de date nu diferă de configurația furnizorului
3 caz - obiectul este schimbat atât acolo, cât și acolo.
astfel încât aici în cazul 1 și 2 platforma se ocupă automat. (Decide care configurație să ia codul de la)
1 asociat cu prioritatea configurației de bază - (mai important, ceea ce se face de către programatori)
2 integrarea cu prioritatea noii configurații a furnizorului - (mai important, ceea ce se face în comunicare)
După actualizarea în modul de îmbinare a codului, se înregistrează o mulțime de înregistrări în eticheta //> MRG Iată un exemplu de bucată de cod din raportul Advance.
De exemplu, în acest moment al codului, este clar că metoda SokrLP () a fost adăugată la lansare;
Și în acest loc al codului au existat îmbunătățiri ale unor AFM (Andropov Fyodor Mikhalych sau altcineva)
Trimiteți-le prietenilor: