The is the workflow of what the new platform does when a new pathway (version) gets added to WikiPathways:
The upgrade of the whole stack is, however, in full swing. Not everything has migrated yet and the RDF generation is not for example.
]]>The is the workflow of what the new platform does when a new pathway (version) gets added to WikiPathways:
The upgrade of the whole stack is, however, in full swing. Not everything has migrated yet and the RDF generation is not for example.
]]>This second post talks about how to migrate code from one repository to another.
While the above works pretty well, a good alternative in situations where you only need to get a repository-with-history for a few plugins, is to use patch sets.
First, initialize a new git repository, e.g. bioclipse.rdf:
mkdir bioclipse.rdf
cd bioclipse.rdf
git init
nano README
git commit -m "Added README with some basic info about the new repository" README
Then, for each plugin discover you need what the commit was where the plugins was first commited, using the git-svn repository created earlier:
cd your.gitsvn.checkout
git log --pretty=oneline externals/com.hp.hpl.jena/ | tail -1
Then create patches for the last tree before that last patch by appending ^1 to the commit hash. For example, the first patch of the Jena libraries was 06d0eb0542377f958d06892860ea3363e3316389, so I type:
rm 00*.patch
git format-patch 06d0eb0542377f958d06892860ea3363e3316389^1 -- externals/com.hp.hpl.jena
(tune the filter when removing old patches if there are more than 99!)
The previous two steps can be combined into a Perl script:
#!/usr/bin/perl
use diagnostics;
use strict;
my $plugin = $ARGV[0];
if (!$plugin) {
print "Syntax: gfp <plugin|feature>\n";
exit(0);
}
die "Cannot find plugin or feature $plugin !" if (!(-e $plugin));
`rm -f *.patch`;
my $hash = `git log --follow --pretty=oneline $plugin | tail -1 | cut -d' ' -f1`;
$hash =~ s/\n|\r//g;
print "Plugin: $plugin \n";
print "Hash: $hash \n";
`git format-patch $hash^1 -- $plugin`;
Move these patches into your new repository:
mv 00*.patch ../bioclipse.rdf
(tune the filter when moving the patches if there are more than 99! Also customize the target folder name to match your situation)
Apply the new patches in your new git repository:
cd ../bioclipse.rdf
git am 00*.patch
(You’re on your own if that fails… and you may have to default to the other alternative then)
Repeat those two steps for all plugins you want in your new repository
]]>For this first post, think of a plugin as a subfolder, tho it even applies to files.
In this case, you remove everything you do not want in your new git repository. Do:
git clone --bare --no-hardlinks old.local.clone/ new.local.clone/
Then use:
git filter-branch --index-filter 'git rm -r -q --cached --ignore-unmatch plugins/net.bioclipse.actionHistory plugins/net.bioclipse.analysis' HEAD
It often happens that you need to run the above command several times, in cases when there are many subdirectories to be removed. When you removed all the bits you need removed, you can clean up the repository and reduce the size considerably with:
git repack -ad; git prune
The 1.2.4 release was soon followed by 1.3.1. Unfortunately, uploading the packages to to SourceForge over 3G with Chrome did not work well, so only finished that today. CDK 1.3.1 is the second release in the development branch, and brings in new functionality but also API changes. Here are the changes since the 1.3.0 release:
56 Egon Willighagen
9 Rajarshi Guha
5 Stefan Kuhn
2 mark_rynbeek
1 Uli Köhler
1 Rajarshi Guha
1 Peter Odéus
1 Paul Turner
1 Miguel Rojas Cherto
1 Arvid Berg
This is just the number of commits, and many of mine are logistic in nature. You can also notice that Rajarshi has changed his name (removed the extraneous space :). Thanx to all of authors for contributing to this release! I am happy to see a few new names in this list, which seems to indicate that the people are settling in on the whole move from Subversion to Git.
This list was created with this command adapted from this StackOverflow question:
git log --pretty=format:%an cdk-1.2.3..cdk-1.2.4 | awk -- '{ ++c[$0]; } END { for(cc in c) printf "%5d %s\n",c[cc],cc; }' | sort -n -r
This overview was created with this Linux one-liner:
git log --oneline cdk-1.2.3.. | sed 's/\([a-f0-9]*\)\s\(.*\).*/<li>\2 <a href="http:\/\/cdk.git.sourceforge.net\/git\/gitweb.cgi?p=cdk\/cdk;a=commit;h=\1">\1<\/a><\/li>/'
Studying this table shows the reasons: there are too many regressions, too many failing unit tests. For example, 1.2.4 (while not yet released, called 1.2.3.git) has 50 new failing tests. Now, fair enough, this is mostly because of ioformats not being tested in 1.2.3 and most of the fails caused by a bug in the test, not in the code. But that still leaves 20 other failing tests. Mostly related to known bugs, and for some problems patches are actually available.
These last 22 we also see in the differences between 1.3.0 and 1.3.1 (while not yet released, called 1.3.0.git). That’s because the ioformats modules is not tested in that branch either, pending a new merge with the cdk-1.2.x branch.
]]>#!/bin/bash
PLUGINS=`ls -1`
for PLUGIN in $PLUGINS
do
echo "************************************************************* $PLUGIN"
cd $PLUGIN; git fetch origin; git status; cd ..
done
The current set of JChemPaint patches looks like:
The two top most branches (bioclipse-2.1.x and 12-ebiStage) are actually staging branches: patches that have not yet been integrated into the JChemPaint-Primary branch. Likewise, the 0-other branch is a staging branch for patches that are in or up for the review process for CDK master itself.
This will mean that I am now going to rebase all these branches once more.
]]>