دنبال فرمانی برای اجرا بگردید…
هر شیء در یک مخزن zev (محتوای یک فایل، یک درخت پوشه، یک کامیت) با هش رمزنگاریشدهٔ بایتهای خودش شناخته میشود، نه با نام فایل یا شناسهای ترتیبی. این پایهای است که همهٔ بخشهای دیگر zev روی آن ساخته شدهاند.
اگر دو فایل در هر جای تاریخچه محتوای یکسانی داشته باشند، هش یکسانی میگیرند و یک بار ذخیره میشوند. اگر فایلی به نسخهٔ قبلی برگردد، هشش دقیقاً با شیء پیشین یکی است و چیز تازهای نوشته نمیشود. نشانیدهی محتوایی این حذف تکرار را رایگان و بهعنوان پیامد مستقیم شیوهٔ هویتدهی فراهم میکند، نه بهعنوان قابلیتی جدا که باید پیاده و همگام نگه داشته شود.
کلاینت و سرور zev عمداً از تابعهای هش متفاوتی استفاده میکنند:
zev) اشیای محلی را با SHA-256 میشناسد که روی محتوای اصلی و فشردهنشدهٔ بلاب محاسبه میشود.zev-api) اشیای ذخیرهشده را با BLAKE3 میشناسد.یک مانیفست ارسال میان این دو نگاشت برقرار میکند: هر ورودی شیء هم local_hash (هویت SHA-256 در کلاینت) و هم server_hash (هویت BLAKE3 که سرور واقعاً با آن ذخیره میکند) را دارد. این جدایی وجود دارد چون دو طرف مستقل از هم تکامل یافتند و مستقل راستیآزمایی شدند: مدل اشیای کلاینت اول ساخته و آزموده شد، و لایهٔ ذخیرهسازی سرور (از جمله فشردهسازی و بعدتر قطعهبندی) بر پایهٔ BLAKE3 طراحی شد، بیآنکه کلاینت لازم باشد شیوهٔ هویت محلی خود را تغییر دهد.
اشیا هم در کلاینت و هم در سرور با zstd فشرده روی دیسک ذخیره میشوند، اما هشی که یک شیء را شناسایی میکند همیشه روی بایتهای اصلی و فشردهنشده محاسبه میشود. فشردهسازی جزئی از پیادهسازی ذخیرهسازی است و هرگز هویت خود شیء را تغییر نمیدهد.
چون هویت صرفاً تابعی از محتواست، دو زیرساخت که مستقل ساخته شدهاند، یعنی قطعهبندی محلی (نگاه کنید به قطعهبندی بر پایهٔ محتوا) و حافظهٔ CI (نگاه کنید به CI حافظهدار)، هر دو با محاسبهٔ هش یک ورودی و بررسی اینکه آیا همان هش پیشتر دیده شده کار میکنند. هیچکدام لازم نبود مفهوم خودش از «آیا این تغییر کرده» را بسازد؛ نشانیدهی محتوایی از پیش یکی را، یکسان و در همهجای سامانه، فراهم کرده است.