On Sat, Jan 10, 2009 at 4:07 AM, TK Soh <[email protected]> wrote: > On Sat, Jan 10, 2009 at 2:15 AM, TK Soh <[email protected]> wrote: >> On Fri, Jan 9, 2009 at 7:01 PM, Steve Borho <[email protected]> wrote: >>> On Thu, Jan 8, 2009 at 9:23 AM, Steve Borho <[email protected]> wrote: >>>> >>>> On Thu, Jan 8, 2009 at 9:16 AM, TK Soh <[email protected]> wrote: >>>>> >>>>> On Tue, Jan 6, 2009 at 3:50 AM, Steve Borho <[email protected]> wrote: >>>>> > On Mon, Jan 5, 2009 at 5:47 PM, TK Soh <[email protected]> wrote: >>>>> >> >>>>> >> On Mon, Jan 5, 2009 at 7:47 PM, Steve Borho <[email protected]> wrote: >>>>> >> > On Mon, Jan 5, 2009 at 1:27 PM, Peer Sommerlund >>>>> >> > <[email protected]> >>>>> >> > wrote: >>>>> >> >> >>>>> >> >> TK has the secret recipe for thg 0.5 (and 0.6, I assume) >>>>> >> >> >>>>> >> >> I'm working on something which tastes a little more of distutil / >>>>> >> >> setuptools, which also replaces the MQ with a forest based system. >>>>> >> >> See http://www.bitbucket.org/peso/thg-distutils-build/ >>>>> >> >> In case anybody feels like joining this they are more than welcome. >>>>> >> > >>>>> >> > I'm wondering if a hybrid approach would be a good idea. >>>>> >> > >>>>> >> > 1) clone mercurial-stable >>>>> >> > 2) pull tortoisehg history and merge >>>>> >> > 3) pull qct history and merge >>>>> >> > 4) create small patch queue to fix up remaining bits >>>>> >> > >>>>> >> > This *uber* repository would be short-lived, only used for building >>>>> >> > the >>>>> >> > installer. >>>>> >> > Only the small patch queue is maintained from release-to-release. >>>>> >> > All >>>>> >> > development >>>>> >> > would still happen on the individual repositories. >>>>> >> >>>>> >> I've thought about the similar approach, but put it aside when peso >>>>> >> announced his intention to work on yet another one. We may give it a >>>>> >> try if it doesn't take too much work to create. >>>>> > >>>>> > I think it would be pretty straight-forward to setup a hybrid approach. >>>>> > We >>>>> > would need >>>>> > to move a few files around to avoid conflicts with hg when we merge. >>>>> > setup.py for one, >>>>> > and probably some READMEs. >>>>> > >>>>> > Then we would make the new simplified patch queue by copying over files >>>>> > from >>>>> > the old >>>>> > setup and making patches out of them. >>>>> >>>>> Sounds good to me. >>>> >>>> I'll give this a try when I get an opportunity. Maybe this weekend. >>> >>> In the short term, I've rebased the existing patch queue to the tip of THG >>> and HG and forest, in preparation for 0.6. You can pull those changes from >>> here: >>> >>> http://www.bitbucket.org/sborho/tortoisehg_installer_mq/ >> >> Actually I've done some similar work in my local repo. But I will look >> at your patch queue to see if I miss out anything. > > I pushed your changes to my mq repo on freehg.org. Thanks.
BTW, I am going to move dist/saved/ to <top>/bundles/ and also move all the gtk files into bundles/. I think it's slightly less confusing (dist/ is a runtime directory), and I can remove dist/ without having to copy the gtk files again. Let me know if you have any concerns. ------------------------------------------------------------------------------ Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB _______________________________________________ Tortoisehg-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tortoisehg-develop
