Skrót DAV rozszerzamy jako „Rozproszona Autoryzacja i Wersjonowanie (ang. Distributed Authoring and Versioning).” RFC 2518 definuje zbiór konceptów i towrzyszących HTTP 1.1 metod rozszerzających, które czynią z sieci bardziej uniwersalne medium pozwalające na zapis i odczyt. Podstawową ideą serwera WWW zgodnego z WebDAV, to fakt, że może zachowywać się jak zwykły serwer plików; klient może „montować” udostępnione foldery poprzez HTTP, który zachowuje się podobnie do innych sieciowych systemów plików (np. NFS czy SMB).

Niestety, mimo jednoznacznej nazwy, RFC tak naprawdę nie definuje żadnego systemu kontroli wersji w specyfikacji protokołu. Proste aplikacje klienckie i serwerowe WebDAV zakładają istnienie tylko jednej wersji bliku bądź katalogu, którą można dowolną ilość razy nadpisywać.

Ponieważ RFC 2518 nie zrealizowało koncepcji wersjonowania, na inny komitet spadła odpowiedzialność napisania kilka lat później RFC 3253. Nowy dokument integruje koncepcję wersjonowania z WebDAVem przywracając literę „V” z powrotem do „DAV”—w ten sposób powstał termin „DeltaV.” Aplikacje WebDAV/DeltaV często są nazywane po prostu aplikacjami „DeltaV”, gdyż użycie tego terminu implikuje istnienie prostego WebDAVa.

Oryginalny WebDAV jako standard całkiem dobrze się upowrzechnił. Każdy współczesny system operacyjny posiada wbudowanego klienta WebDAV (szczegóły później), poza tym obsługuje go wiele aplikacji takich jak chociażby Microsoft Office, Dreamweaver, czy Photoshop. Jeżeli chodzi o serwery, to Apache jest w stanie dostarczać usługi WebDAVa począwszy od 1998 i uznanwany jest de facto za standard wśród aplikacji open source. Istnieje też kilka serwerów komercyjnych jak chociażby ISS Microsoftu.

Pech chciał, że DeltaV nie udało się powtórzyć sukcesu swojego poprzednika. Obecnie bardzo trudno jest znaleźć jakiekolwiek aplikacje obsługujące ten standard. Istnieje kilka słabo znanych programów komercyjnych, przez co trudno przetestować ich możliwości interoperacyjne. Nie jest do końca jasne, co było przyczyną stagnacji DeltaV. Niektórzy twierdzą, że specyfikacja jest po prostu zbyt skomplikowana. Inni argumentują, ze o ile WebDAV stosowany jest masowo (nawet mało doświadczeni użytkownicy doceniają zalety udostępniania plików w sieci), o tyle kontrola wersji nie jest już tak interesująca i przydatna dla większości użytkowników. Niektórzy uważają też, że DeltaV nie spopularyzował się z powodu braku dobrego darmowego serwera.

Kiedy Subversion było jeszcze w fazie projektowej, wykorzystanie Apache'a jako serwera sieciowego wydawało się świetnym rozwiązaniem. Posiadał już moduł udostępniający usługi WebDAV; DeltaV w tym czasie była relatywnie świeżą specyfikacją. Wiązano nadzieję, że moduł serwerowy Subversion (mod_dav_svn) powoli ewoluuje do implementacji DeltaV o otwartym kodzie Niestety, DeltaV posiada bardzo specyficzny model wersjonowania który nie do końca jest zgodny z modelem Subversion. Niektóre założenia dało się odzwierciedlić, inne już nie.

Co to zatem oznacza?

Po pierwsze, klient Subversion nie jest pełną implementacją klienta DeltaV. Wymaga od serwera pewnych funkcji, których DeltaV sam w sobie nie udostępnia i jest mocno uzależniony od grupy specyficznych dla Subversion żądań HTTP REPORT, które rozumie tylko moduł mod_dav_svn.

Po drugie, mod_dav_svn nie jest w pełni zrealizowanym serwerem DeltaV. Spora część specyfikacji była całkowicie zbędna Subversion, przez co została pominięta podczas implementacji.

Wciąż trwa debata pośród programistów, czy warto coś zrobić, by tą sytuację zmienić. Nierealistyczne jest modyfikować model Subversion, aby go dopasować do DeltaV, ponieważ nie da się prawdopodobnie stworzyć takiego klienta, który byłby w stanie pobrać wszelkie potrzebne mu informacje od zwykłego serwera DeltaV. Z drugiej strony, mod_dav_svn mógłby być rozwinięty w kierunku implementacji wszystkiech funkcji DeltaV, lecz trudno zmotywować się do takiego zadania skoro praktycznie nie istnieje żaden klient z którym mógłby współpracować.