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.
We also need to copy the qct.py extension from plugins/ to hgext/
--
Steve
------------------------------------------------------------------------------
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
