Hi Charles, >>>Again - if there's somebody familiar with perl, CVS and subversion, who >>>wants to port buildtool and genpage, they're more than welcome to do so >>>(and I'd do my best to help as much as I can). > > > Subversion can generally be used as a 'superset' of CVS, and quite a bit > of the command line is identical, particularly for the common uses > you've probably got coded into your tools (ie: checkout, update, > commit), so converting could be as simple as substituting svn for cvs > (unless you're using some perl module to directly access CVS w/o using > the command-line client). that is the case for buildtool (to work around the constant problems with viewcvs, we're using a lib that uses CVS on a very low level - if I understand correctly, it re-implements the CVS protocol, but you'll need to ask Arne about details). Genpage relies heavily on the output of "cvs log" (for the changelog section). I know that the command line utilities of cvs and subversion can pretty much be used interchangeably, but I doubt that's the case for the output of the commands, which is then parsed by a perl script (and I'm rather sure it's not true on the protocol level ).
If it were only about how the commands were invoked, that would be relatively easily solved (hopefully, that kind of thing is kept in a few, easily identified places in the tools) - what I'm worried about is that we rely on the specific behaviour and output of the commands. Not having done anything more than a simple checkout with subversion so far, I can't say if that concern is valid - but so far, nobody has convinced me that I'm wrong... > ...of course, even if the conversion is easy, everything takes some > work, and usually more time (especially regression testing!)... Yup, indeed. > Yeah, that's why I figure it's worth it to start keeping a backup > rotation of our CVS directory from SF. Absolutely - and I'd be very greatful if you could tackle that job (unfortunately, I don't have to bandwidth to try - rsync is great, but if the first sync takes several days, it makes things difficult ;-)) > I'm sure we'll eventually > migrate to subversion, but it probably won't be until some critical need > forces the issue. :) Right - as always, such things aren't approached until one is forced to (and it makes some sort of sense too - lets say it's easy, and it "only" takes a weeks work of everybody involved to make the conversion. After we're done, we've spent several "man-weeks" worth of spare time, and the end result is that we have exactly what we have right now, just on a different SCM - hard to explain that to wifes and families...). > NOTE: I have overseen the conversion of a very large CVS archive into > subversion (the source code for a commercial 3D graphics package), and > it's fairly painless using the automated scripts provided with > subversion for that purpose. So at least that part *SHOULD* be easy. :) That's good news. The thing is, if we have a good backup, we could even live with losing the history when porting to something else (since one could always go to the old CVS repository if one needs an old snapshot). It's migrating to something else and getting all the tools to provide what we have right now that I'm worried about. Martin ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
