rebar3.git - Clone of https://github.com/erlang/rebar3

	Commit message (Collapse)	Author	Age	Files	Lines
*	Do not use application:set_env	Tuncer Ayaz	2012-07-23	1	-8/+11
\|
*	Remove shared state	Tuncer Ayaz	2012-07-13	1	-3/+3
\|
*	Fix whitespace errors	Tuncer Ayaz	2012-01-09	1	-16/+25
\|
*	Fix Dialyzer warning	Tuncer Ayaz	2012-01-09	1	-4/+7
\|
*	On windows, avoid symlink during upgrade	Matt Campbell	2012-01-09	1	-5/+17
\| \| \| \| \| \| \|	a) make_symlink throws "not supported" on OS < Vista (e.g. 2003) b) tarball creation stores windows symlinks as absolute paths instead of relative, causing service to fail to start after upgrade is made permanent.
*	Better code path handling during upgrades	joewilliams	2011-10-17	1	-4/+3
\| \| \| \| \| \| \|	While building a upgrade package rebar will add new paths to the internal erlang path, these paths and their order have effects on how the package is built. This patch should fix some corner cases where a user can receive a "undefined application" error.
*	Copy sys.config into upgrade tarball	joewilliams	2011-10-17	1	-0/+5
\| \| \| \| \| \|	While building an upgrade the sys.config file should be copied into the upgrade tarball so release_handler:install_releases/1 does not clobber the existing configuration from the application environment.
*	More descriptive logging for upgrade systools cmds	joewilliams	2011-10-15	1	-9/+14
\| \| \| \| \|	In debugging upgrade issues it is sometimes difficult to know which systools step a error ocurred at, a little extra logging to fix that.
*	Handle vm.args properly while building upgrades	joewilliams	2011-10-05	1	-1/+4
\| \| \| \| \| \| \|	This patch corrects the vm.args behavior while building upgrade tarballs by copying the file from the release into the upgrade. Additionally it patches the dummy runner script in the upgrade test project to work properly.
*	Get rid of app.config	joewilliams	2011-09-20	1	-8/+9
\| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \|	app.config has been a long standing erroneous file in rebar. Erlang/OTP documentation suggests a sys.config file instead. This file is stored in the releases/VSN directory. This does a few things but most importantly it ensures your config (contained in the application environment) survives a hot upgrade. It also has the advantage of allowing the configuration of the application to be versioned along side the application code. This patch flips rebar to use sys.config rather than app.config. Additionally it makes this flip to vm.args as well, making them versioned just like sys.config. This patch also includes runner script changes to support the old etc/app.config config file location and support for Windows. Thanks to mokele for the initial work and kick in the pants to make this finially happen.
*	look for new and old versions in the target parent	Steven Gravell	2011-07-01	1	-35/+55
\| \| \| \| \| \| \| \| \| \| \|	The target_dir config in reltool allows you to put your release in a directory other than in ./NAME, so we should look in the parent directory of that to find the new and old versions instead of simply looking in ./ Move untaring and retaring into a temporary path instead of in ./ to prevent name collisions with "releases" and "lib" that might exist already. Having a subdirectory rel/releases/ can be useful.
*	Apply Tidier suggestions	Tuncer Ayaz	2011-06-02	1	-2/+3
\|
*	Clean up trailing whitespace	joewilliams	2011-02-17	1	-1/+1
\|
*	Clean up rebar_appups and rebar_upgrade	joewilliams	2011-02-17	1	-59/+37
\|
*	Clean up code	Tuncer Ayaz	2011-02-06	1	-4/+6
\|
*	Clean up emacs file local variables	Tuncer Ayaz	2011-01-31	1	-1/+1
\|
*	Fix Dialyzer warnings in rebar_upgrade	Tuncer Ayaz	2011-01-29	1	-2/+2
\|
*	Add 'generate-upgrade' command	joewilliams	2011-01-27	1	-0/+206
	To support OTP release upgrades I have added support for building upgrade packages. Support for this is included in the rebar_upgrade module, specifically generate_upgrade/2. It requires one variable to be set on the command line 'previous_release' which is the absolute path or relative path from 'rel/' to the previous release one is upgrading from. Running an upgrade will create the needed files, including a relup and result in a tarball containing the upgrade being written to 'rel/'. When done it cleans up the temporary files systools created. Usage: $ rebar generate-upgrade previous_release=/path/to/old/version This also includes a dummy application that can be used to test upgrades as well as an example. Special thanks to Daniel Reverri, Jesper Louis Andersen and Richard Jones for comments and patches.