On Mon, Jan 19, 2009 at 3:42 PM, Peer Sommerlund
<[email protected]>wrote:
>
>
> 2009/1/18 Steve Borho <[email protected]>
>
>> I pushed a large number of changes to the forest based installer today,
>> now that 0.6 is out of the way.
>>
>> * I added hgforest-crew to the forest
>> * The batch file copies forest.py and qct.py from their respective
>> repositories
>> * All files added by MQ patches were checked into forest thg-installer
>> repo
>> - icons, bitmaps, kdiff3, plink. All these patches are now gone
>> * All files required by the install were checked into dist/ (add-path,
>> mfc*.dll)
>> * I even checked in the etc/ lib/ and share/ directories out of the 0.6
>> install so those files don't
>> have to be re-trimmed by everyone. All of this is under dist/ in the
>> forest repo.
>
>
> Since the files in dist are not controlling the build process, I think it
> would be better to place them in a separate repository.
> "thg-installer-dist", maybe?
>
Makes no difference to me. A forest is a forest, the number of trees hardly
matters. A single repository is only a tad simpler.
>
>> * The batch file no longer merges Qct source, it just grabs the extension
>> * hg-config and Qt are completely unbundled
>> * the patch queue which gets applied to the final uber-repo is now very
>> small
>> - it only modifies existing files
>> - it doesn't touch anything inside of mercurial/
>> * build.bat now builds everything
>>
>> I was able to clone the thg-install repo, then run the build.bat to create
>> an installer. Each
>> time we cut a release using this method, we'll simply run 'hg fsnap >
>> releases/0.7.snap',
>> add the file and check it in. You can then 'fupdate' to any of those
>> snapshots to reproduce
>> that build.
>
>
> I would rather fsnap > installer.snap and tag the forest repository. This
> would also restore the support files (like build.bat) to match the build
> process
>
That would be ok if we immediately checked in a new version of
installer.snap after each release that specified the tips again. I wasted a
lot of time fighting with forest about which revisions it should be
pulling. While you're developing, you don't want to be continually updating
the snapshot file.
It would also be ok if there were two snapshot files, one for development
(with tip revisions) and one that's tagged each release.
When you generate a snapshot, it records the version of the forest repo
itself as well, so when you fupdate to it you will get back the script
versions you were using for that release.
--
Steve
------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Tortoisehg-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tortoisehg-develop
