Front page | perl.perl5.porters |
Postings from February 2007
Nicholas Clark wrote: > There's a lot of things that predate the current maintainers, and many lines > of code that are the (in)famous change 1 > > Change 1 by mbeattie@localhost on 1997/03/28 13:17:33 > > Perl 5.003 check-in > > http://public.activestate.com/cgi-bin/perlbrowse?show_patch=Show+Patch&patch_num=1 Well, the history at http://git.catalyst.net.nz/gitweb?p=perl.git;a=shortlog;h=restorical Doesn't suffer from that problem. It's far from complete - there were several old perl releases that weren't available on history.perl.org, and I didn't have the old RCS files that were originally used to maintain the code for more fine grained conversion of the early perls. Some of the releases didn't ship with per-file change comments, so they become just one revision. Also, some of the messages in the perl5-porters referred to by Chip's pumpking era don't seem to be in the archives, which is a bit of a shame because the history is much more useful when you get a bit of a story with each commit message. Although that's not technically in the history of the Perforce repository, it might be good to see which of those changes were merged. I'm currently working on grafting the Perforce history on top of the point where it most cleanly fits, ie the 5.003 release. You'll see various branches in that repository that capture some of this effort. In case it is not clear MOST OF THE BRANCHES IN THAT REPOSITORY WILL BE REBASED - DO NOT PULL THEM UNLESS YOU WANT TO HELP WITH THE HISTORY CONVERSION. Probably only the "restorical" branch won't change enough to worry about from now, unless I get a significant new source of revision information. See also http://git.catalyst.net.nz/gitweb?p=perl-history-massage.git;a=blob;h=8f0af83c;hb=e1542030;f=README.txt I was meaning to get a bit further and announce it, but hidden in an obscure branch of this flamewar will do for now ;) I've still got a bit of cleaning work to do, but I could really do with perforce access, or preferably somebody with the appropriate knowledge to extract all of the integrate / branch information from the repository and give it to me in some easily mungable form. Actually the information is mostly there in the commit messages, and it would probably be good to go through the process of reverse engineering the merge information from the commit log messages and comparing it to the metadata - often the metadata is just as bad or worse than the manually recorded information. Then there will just be the task of making sure that the maintenance scripts work with the repository. And after that people can create their own little feature branches for whatever new features they want and things won't suck. In fact moving away from the outdated "blead/trunk/feature ghetto" development style would probably be a good idea in general. Wikis suck even if they track changes atomically over SSL WebDAV. Sam.