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.
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.
1-5 of 5
Reply to this discussion
You cannot edit posts or make replies: You should be logged in before you can post.