Forums : Ohloh General Discussion

I wanted to give a heads up that the BRL-CAD repository will be migrating from CVS to SVN over the next few days (assuming no problems are encountered) and wanted to see if there's anything special I should do beforehand with respect to our ohloh enlistment. Reading through the forums, it seems like the only steps really needed are to remove the old enlistment and add our new enlistment.

The plan as it stands is to add our new svn enlistment, verify/compare the enlistment results, and then remove our current cvs enlistment. Does that sound viable? Is there anything else we should do (or if you'd like us to be a guinea pig for the new svn enlistment method), please let me know.

I don't yet have hard/final numbers but the CVS repo is about 650MB and the SVN dumpfile is about 3GB so the final SVN is probably going to be somewhere in between.

Cheers!
Sean

sean over 17 years ago

As far as the ohloh process, you are right: add the new SVN repo and remove the old CVS.

Regarding cvs2svn (which I assume you're using - if it's something else, ignore the following), take a look at this thread http://www.ohloh.net/forums/10/topics/406, particularly Nathan's comments, about errors people ran into with the program. Another problem I've recently found which we haven't figured out how to fix yet is that some versions of a file in the history might be truncated.

-Andy

PS This is pretty obvious and I'm sure you're already planning it but adding in case others run across the thread: It seems like a good idea to keep the cvs repository around for a while after the conversion to help fixup any issues.

Andy Verprauskus over 17 years ago

Andy,

Thanks for the prompt reply and link to the thread about the svn log failures. That was on my list of (several) validation steps that will be taken to ensure our repository converts faithfully as it's a really big deal for us to preserve our history completely and correctly. I'll be sure to pay special attention to any log errors, though, and if you have a command that can be run to check for truncated history, I'll add that to the list aside from some manual sanity checks. Ohloh metrics are actually a part of our overall validation, so thanks as always for the great service.

Cheers!
Sean

sean over 17 years ago

Hope the conversion is going well.

Unfortunately I don't have a command to run to help validate.

Andy Verprauskus over 17 years ago

So far everything is going well and I should be adding the svn enlistment in a few hours as soon as the upload to Sourceforge completes. We've had several relatively minor issues to sort out in our repository on the whole, a few bugs in cvs2svn uncovered that seem to be unique to the age of our CVS repository, but no show stoppers (just tedium). Our log, checkout, and spot tests have all passed just leaving ohloh enlistment comparisons remaining. I've just had to perform the conversion a couple times over to ensure mime types, permissions, and deal with one checkout validation failure. Having all .tcl files import with the mime-type of application/x-tcl and Subversion treating it as binary was really not helpful.. :-)

I'll drop a note when the enlistment completes, hopefully with good news. Either way, thanks again for your advice and support.

Cheers!
Sean

p.s. For others running across this thread, our conversion efforts are being documented here on our website.

sean over 17 years ago

Ahh...so close. As (it says) you are already aware, our SVN enlistment failed on step 2 after several hours of processing. If it's something we can review/fix on our end, please let me know. Otherwise, I'll be (patiently and quietly) waiting to see the results. :-)

Cheers!
Sean

sean over 17 years ago

The error was on our end. I added some additional hardware to our database server today and BRLCAD's and a couple other long running jobs died in the process.

I restarted the import and it's chugging along now.

Andy Verprauskus over 17 years ago

Well, Andy -- thank you very much for your help. The enlistment looks to be complete and a complete success. One interesting side-effect, though.. If I recall correctly, our CVS enlistment report summarized to 485 years of effort while the SVN repo is coming in at roughly 510 years of effort. Granted the SVN update includes a commit that touched all files (copyright update), but I doubt that counts for 25 years of effort.. ;-)

It's also interesting to note that the SVN and CVS commit log messages handle the commit log message differently (or was changed via cvs2svn). The SVN commits seem to all have a trailing newline, the CVS ones do not. That still wouldn't likely account for the total effort difference either.

Is there a way to compare the difference between the two enlistments, why one would be greater/less than the other -- particularly since the commit counts do seem right overall.

Cheers!
Sean

sean over 17 years ago

Okay, I've investigated the differences between the CVS and SVN enlistment, compared them to my notes before the SVN enlistment, and think I now have a pretty good grasp of all the differences possibly even explaining the 7% increase (34 years) of overall effort that is reported for the SVN repository. None of the differences are of concern, fortunately (kudos!), but I did think you might find the differences interesting as they pertain to how Ohloh indexes and attributes commits for an enlistment -- there are some rather interesting differences between having a CVS repository and an SVN repository. In brief, the things I noted are as follows:

1. SVN property changes are being attributed as source code changes. This is possibly the bulk of the 7% difference as it adds minimally a +1-1 change to every commit due to the CVS revision numbers being stored as SVN properties (an option we opted for during cvs2svn). With 28700 SVN commits, that's minimally -28700+28700 line changes being counted.

2. Ohloh does a much better job at collapsing related CVS commits into one change event (presumably based on time and commit message) than cvs2svn does. Ohloh counted 27661 CVS commits and reports approximately 28689 SVN commits. I would presume you're taking SVN commits as-is given SVN performs atomic commit transactions, so you don't need/try to collapse them. Might be useful to do the same collapse for all repository types based on the log/timeframe for consistency, though it's certainly a minor difference.

3. Perhaps entirely unrelated to another change that was just made, but Ohloh now correctly finds our BSD licensed files. All of our file counts doubled perfectly except for our BSD license count. Before with CVS, it counted 2 (which was quite wrong). Now it counts 171 files, presuming Ohloh's BSD detection didn't change this week. That number is a bit higher than my back-of-the-envelope quick grep counts, but it's within the ballpark.

4. As already noted, it's interesting that the SVN commit log messages all seem to include a trailing newline whereas the CVS commit log messages do not.

5. The Lines Modified metric was one that I really couldn't account for but did find it exceptionally interesting in the magnitude of the differences. Most of the user commit counts were about +3% and line change counts were about +- 3% different. Would hypothesize that the difference is simply the uncollapsed SVN commits. The only one that raised an eyebrow was where one user (johnranderson) gained an astonishing +269K lines credited to them, where everyone else was over or under by a few thousand lines or less for the SVN enlistment.

Cheers!
Sean

sean over 17 years ago