Martin, github pretty much requires a "master" branch, but it doesn't have to be named "master" ... For FileTree where I use the branch per platform approach, the master branch is where I stash the cherry-picked common code ... then all of the platform branches can merge at their leisure ... If you look at the network graph for FileTree[1] you can see the pattern.
Dale [1] https://github.com/dalehenrich/filetree/network ----- Original Message ----- | From: mkobe...@gmail.com | To: "Frank Shearar" <frank.shea...@gmail.com> | Cc: "The general-purpose Squeak developers list" <squeak-...@lists.squeakfoundation.org>, "Pharo Development" | <Pharo-project@lists.gforge.inria.fr> | Sent: Thursday, April 18, 2013 7:14:34 AM | Subject: Re: [Pharo-project] [squeak-dev] Xtreams's FileDirectory dependence | | As Jan mentioned, in https://github.com/mkobetic/Xtreams I'm primarily just | experimenting with Cypress. However the master branch there is misleading, | it contains a very early port of Xtreams to ST/X (there's a much more up to | date version in Jan's ST/X project @ | https://swing.fit.cvut.cz/jenkins/job/xtreams_reports/). | | However if you look at some of the other branches in the github project you | can find a fairly up to date, Cypress formatted dump from VW as well as the | results of Sean's ESUG effort to add namespace-prefix mapping to Filetree | (branch pharo_experiment). My ultimate goal is to test Dale's idea to | maintain a cross-dialect project as parallel branches in git. However we | still need to iron out various dialect differences in terms of what they | emit as Cypress formatted output. BTW, does anyone know if git/github can | handle absence of a master branch? I'd be inclined to just delete the master | from the repository if that works well. | | I've been planning to ping Sean about his Filetree fixes for a while, but I | need to find the time to be able to actually act on it :-). The | prefix-namespace mapping is crucial to make the parallel branch approach at | all feasible. There's also the Environment effort on Squeak side which may | obviate the prefix mapping need, but it seems to be still in fairly early | stages. | | So far it was mostly Nicolas' manual effort that brought VW updates over the | Squeak/Pharo side. I think it was a while since the last time he's done | that, so the VW port is probably ahead somewhat. But Xtreams development | isn't that active anymore. Most of our Xtreams related efforts are about | using them for various things, so any changes are mostly fixes or small | improvements driven by that use. So in some sense a manual update could be a | feasible approach at this point. But I would really like to turn the project | into a more collaborative effort, where updates can flow reasonably in any | direction. | | While I'm on the topic, I'm considering some API changes and am not sure how | to go about discussing it. I don't want to cross post discussions to a | number of mailing lists, so I think I'm inclined to just cross-post an | invitation to anyone interested to subscribe to the Issues on the project | site (https://code.google.com/p/xtreams/) and have those discussions there. | Any thoughts on that? | | "Frank Shearar"<frank.shea...@gmail.com> wrote: | > How up to date is https://github.com/mkobetic/Xtreams/ ? That's surely | > not the "canonical" repository, which would be in the Cincom Smalltalk | > Public Repository. I think? Anyway, assuming it's up to date, one | > promising approach to using Martin Kobetic's repository directly is: | > * have a way of importing chunk format stuff from a GitHub repository | > (see Squeak's inbox for my | > doesn't-support-filetree-yet-but-can-do-chunk-format InstallerGitHub | > (and I plan to submit a Gofer patch to do the same)) | > * load into an Environment (Squeak 4.5 can do this, modulo its alpha | > state). | > | > It might even be possible to import into an Environment with the | > prefix-adding import and then fileout/monticelloise the resulting | > things as a prefix-using, non-Environments-requiring blob ready for | > everyone to use. | > | > frank | > | | |
