On Sun, Jan 11, 2009 at 12:57 AM, Steve Borho <[email protected]> wrote: > On Sat, Jan 10, 2009 at 6:39 PM, TK Soh <[email protected]> wrote: >> >> On Sat, Jan 10, 2009 at 5:09 PM, Steve Borho <[email protected]> wrote: >> > On Sat, Jan 10, 2009 at 7:45 AM, TK Soh <[email protected]> wrote: >> >> >> >> On Sat, Jan 10, 2009 at 7:15 AM, Steve Borho <[email protected]> wrote: >> >> > On Sat, Jan 10, 2009 at 12:13 AM, Steve Borho <[email protected]> >> >> > wrote: >> >> >> >> >> >> These commands seem to get us most of the way there (assumes you are >> >> >> in >> >> >> a >> >> >> directory with hg-stable, tortoisehg-dev, and qct): >> >> > >> >> > Ok, I'm done for the night. I've pushed two new changes here: >> >> > http://www.bitbucket.org/sborho/tortoisehg_installer_mq/ >> >> > >> >> > The first commit re-organizes the patch queue so it works on top of >> >> > this >> >> > new >> >> > uber-repository. I also cleaned it up so no two patches touch the >> >> > same >> >> > file. >> >> > >> >> > The second commit checked in the shell script I use to build the >> >> > uber-repository; I checked it right into the patch repository. To >> >> > use >> >> > it, >> >> > just copy the script into a directory that has a clone of my patch >> >> > repo, >> >> > a >> >> > clone of hg or stable, a clone of tortoisehg, and a clone of qct. >> >> >> >> The installer is targeting Windows platform, so it seems strange to >> >> have it as sh script instead of .BAT file. In any case, since I have >> >> sh.exe installed as part of MSYS, I could just run it out of the patch >> >> repo without needing to copy it out. >> > >> > It can be turned into a batch file, it was just convenient for me to >> > make >> > a shell script at first since I'm not running Windows right now. >> >> When converted to batch file, it stops running after the first hg >> operation (clone). It might have something to do with me running hg >> via hg.bat, but I don't have the explanation to this now. Same problem >> with .CMD file. > > dos/unix eoln > >> >> >> >> >> > Update the repo names in the script as necessary, then run it. It >> >> > should >> >> > take about 15-20 seconds depending on your HW. >> >> >> >> What do we do if we need to build, say, TortoiseHg 0.5 with Mercurial >> >> 1.0.2, etc? >> > >> > You can merge any arbitrary changesets/tags of the three repositories. >> > There's >> > no rule that says you can only merge heads. >> >> When I did it, hg pick up the the last merge's changeset id as >> revision, so 'hg version' give "<merge cset id>+tortoisehg", instead >> of "1.0.2+tortoisehg". So, how do we tell exactly which version of hg >> we are linking to, especially since the id display is foreign to >> Mercurial's repo? > > Yes, that will be a problem. When we just used a patch queue, we were able > to report qbase. That won't be an option now. We'll probably have to > hard-code the version reported by Mercurial, or at the last make it lookup > the tag that we merged with.
What do you mean by hard-code? I am wondering if we should do this re-org after 0.6. We still target to release 0.6 in another week. > We also need to copy the qct.py extension from plugins/ to hgext/ Which can be done by the patch queue? ------------------------------------------------------------------------------ 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
