Understanding SVN repository filesystem

Hi,    I am trying to understand the subversion repository filesystem and the document  Subversion Design helped a lot.    There is something that is not yet clear to me:  As I understand, SVN stores the latest version of a file as full-text and the  ancestor as a reversed diff so that in order to checkout the ancestor, SVN first has to apply the reversed patch. Right?  So far, everything's allright.      But imagine the following situation:  ------  svn add fileA  svn commit  Commmitted Revison 1    svn copy fileA fileB  svn commit  Committed Revision 2    svn status  M fileA  svn commit  Committed Revision 3  ------    Now, obviously fileA (r3) is stored as fulltext.  What about fileB (r2)? fileB is the newest version of fileB - so it should be stored as fulltext, too.      fileA (r1) should be stored as diff to it's descendant. But to which descendent?  Actually, both fileA (r3) and fileB (r2) are descendents of fileA (r1).  the diff fileA (r1) against fileB (r2) would be empty, because these two files  are identically, while the diff against fileA (r3) would reflect the changes made in  revision 3.  Now, which diff does subversion choose?      Perhaps, someone could explain this or point me to a solution?  And how does it go on when i commit changes to fileB and fileA later on?    The reason I ask is that I am trying to rebuild a svn-like repository using SQL.

Last updated 19 years ago

Why are you trying to rebuild SubVersion functionality in SQL Server? Why not just figure out a way to integrate subversion into your application? They have already done all of the hard work about thinking about these problems...

Better yet, why not implement a database-backend for Subversion. It is designed for pluggable storage implementations, I believe.

I am trying to understand how Subversion works .. is that so unusual? :)

Ben Collins-Sussman answered my question over at the #svn channel.  Here's the text if anyone is interested.    

sussmanhere's what happens  commit r1: fileA is fulltext.  commit r2: fileB and fileA both point to the exact same node, which is still fulltext.  commit r3: fileA points to a *new* node that is fulltext. the r2 fileA points to the older node, which is now rewritten as a delta against the newest node.  meanwhile, fileB still points to that same 'delta' node.  which means, in order to read the contents of fileB,  you must apply the old fileA delta to the the new fileA fulltext node.