On Sun, Jan 11, 2009 at 1:17 AM, Steve Borho <[email protected]> wrote: > On Sat, Jan 10, 2009 at 7:02 PM, TK Soh <[email protected]> wrote: >> >> 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? > > The installer patch queue has always patched version.py file so 'hg version' > returns $qbase+tortoisehg.
I've been wondering if we really should add "+tortoisehg" to hg version. While it help points to the hg.exe in tortoisehg, it may give a wrong impression to some people that we have patched mercurial core, which we don't. > The build batch file should probably run 'hg id -qr HG > HG-VERSION' > and then version.py should read that file. Do you mean tortoise/version.py? But that will have no effect on 'hg version'. >> >> I am wondering if we should do this re-org after 0.6. We still target >> to release 0.6 in another week. > > It's up to you how you build 0.6. I'm just trying to lower the barrier to > entry for contributors. > This shouldn't hold up the release. > >> We also need to copy the qct.py extension from plugins/ to hgext/ > >> Which can be done by the patch queue? > > Probably better to be done by the batch file, just after qct is merged we > can hg cp that file into place. That way the patch queue doesn't need to be > updated if that file changes. Good use of mq ;-) ------------------------------------------------------------------------------ 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
