Cool, I am currently using git to keep track of bleadperl and my branch, but I don't have the history, and my method of importing new changes from bleadperl is horrible (I often end up doing a rsync to just get all the changes). Can I get a clone of the repository? I know brances will be rebased etc, but it is far far better then what I have now. I tried: cg-clone git://git.catalyst.net.nz/public/perl.git#restorical but it only gave: defaulting to local storage area Fetching pack (head and objects)... fatal: unexpected EOF cg-fetch: fetching pack failed Gerard Goossen. On Tue, Feb 06, 2007 at 09:35:58PM +1300, Sam Vilain wrote: > 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.