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. ------------------------------------------------------------------------------ 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
