2009/1/19 Steve Borho <[email protected]>
> On Mon, Jan 19, 2009 at 3:42 PM, Peer Sommerlund <
> [email protected]> wrote:
>
>>
>>
>> 2009/1/18 Steve Borho <[email protected]>
>>
>>> 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.
That is a good idea. How about development.snap and stable.snap
"build.bat" would build the development
"build.bat stable" would build the stable version
>
>
> 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.
Are you sure about that? I don't think it is used for anything. If it was
true, then repeated run of fupdate would find older and older revisions.
Regards,
Peer
------------------------------------------------------------------------------
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
