Over the last couple of nights I’ve been trudging thru some code, mostly in perl, to allow bonsai to work with Subversion repositories. All in all pretty fun stuff.
The first thing I did was kind of a sanity check to see if svn commit data has all of the information that bonsai expects — I wanted to see if I would need to generate any information required. To determine this I took a look at bonsai’s dolog.pl and rebuildcvshistory.cgi — both populate the files and checkins tables in the bonsai database.
dirs table
| Column |
Type |
Comment |
| id |
Integer |
Primary key |
| dir |
VarChar(255) |
directory (relative to repository) |
files table
| Column |
Type |
Comment |
| id |
Integer |
Primary key |
| file |
VarChar(255) |
filename (filename only – does *not* contain path) |
checkins table
| Column |
Type |
Comment |
| type |
Enum |
‘Change’, ‘Add’, ‘Remove’ |
| ci_when |
DateTime |
Timestamp of the revision |
| repositoryid |
Integer |
Foreign Key (FK) into repositories table |
| dirid |
Integer |
FK into dirs table |
| fileid |
Integer |
FK into files table |
| revision |
VarChar(32) |
revision identifier |
| stickytag |
VarChar(255) |
tag identifier |
| branchid |
Integer |
FK into branches table |
| addedlines |
Integer |
number of lines added for this revision |
| removedlines |
Integer |
number of lines removed for this revision |
| descid |
Integer |
FK into descs table |
Now, while I haven’t dumped all of the tables, the above should give you a feel for how it’s structured. What is interesting to note is that while the checkins table has columns for branch and even stickytag, they don’t seem to be populated.
The heart of the bonsai system is the checkins table shown above where each row holds the information for each unique revision of each file. When this table is populated from CVS the rcs file list is crawled (all of the ,v files you see if you look at an actual CVS repository) and rlog is run on each file to pull it’s revision history which is inserted into the table.
With SVN it is a little bit different – not much, but still different. SVN uses atomic commits so multiple files can be included for each revision and given that you can rename and move files and directories, you end up with an interesting design hitch: Do you use svn list to return the list of files and directories in the root of the SVN repository and walk that list using svn log or do you use svn log on the root of the SVN repository and as part of the walk thru the revision history you will get all files and directories.
Now for the part of bonsai that is updating the tables for each new checkin it’s kind of a moot point (still a fun point, but made moot by how SVN does it’s hooks.) During the post-commit hook you get the repository and revision number so it really makes it a no-brainer to use the svn log command and parse the info into checkins table insertions for each file touched.
For the part of bonsai that does the initial building I can see it going either way but currently I’m leaning towards the svn log method simply because that would allow me to have a common svn log parser routine. Code reuse is a Good Thing :)
I still need to chew it over in my head but so far I haven’t seen any show stoppers, only a couple of questions that need working out. One of the questions is that by doing it the svn log way it changes how bonsai works with SVN from how it works with CVS. Not that I consider that a “bad” thing – just making note of it.
Hmm, this has turned out to be a nice rambling post so let me end it now and I’ll continue it after I’ve run OSAF’s cvs repository thru one bonsai and the svn repository thru another to make sure I’m getting the same insertions. woo fun stuff!
