Bazaar - Revision history

Cadillac at 01:28, 23 August 2021

2021-08-23T01:28:02Z

← Older revision		Revision as of 21:28, 22 August 2021
Line 235:		Line 235:

	{{Sections}} <!-- Template:Sections should be at the top of each section -->		{{Sections}} <!-- Template:Sections should be at the top of each section -->

			[[Category:Development]]

Z-man: /* Tools you need */

2009-01-13T15:10:19Z

Tools you need

← Older revision		Revision as of 11:10, 13 January 2009
Line 17:		Line 17:
	To fetch development branches or the trunk using Bazaar, you need [http://bazaar-vcs.org/ Bazaar]. You should make yourself familiar with the basic documentation.		To fetch development branches or the trunk using Bazaar, you need [http://bazaar-vcs.org/ Bazaar]. You should make yourself familiar with the basic documentation.

	To contribute back, we recommend you "rebase" your work before we integrate it, if possible; this makes all integration conflicts happen to you, and not the poor merging operator. You'll need the [http://bazaar-vcs.org/Rebase bzr-rebase] plugin for that.		To contribute back, we recommend you "rebase" your work before we integrate it, if possible; this makes all integration conflicts happen to you, and not the poor merging operator. You'll need the [http://bazaar-vcs.org/Rebase bzr-rebase] plugin for that. Alternatively (rebase is somewhat picky and doesn't work most of the time), you can of course supply an already pre-merged branch with conflicts resolved.

	To take over the merging operator duty and manage the two way syncing of the Bazaar branches and SVN, you'll need the [http://bazaar-vcs.org/BzrForeignBranches/Subversion bzr-svn] plugin and its somewhat difficult dependencies. Difficult unless you run Ubuntu, then you get everything you need apart from the plugin itself. Lucky bastard.		To take over the merging operator duty and manage the two way syncing of the Bazaar branches and SVN, you'll need the [http://bazaar-vcs.org/BzrForeignBranches/Subversion bzr-svn] plugin and its somewhat difficult dependencies. Difficult unless you run Ubuntu, then you get everything you need apart from the plugin itself. Lucky bastard.

Z-man: /* Distributed, shmistributed. I just want to work on the mainline or someone else's development branch. Is there no simple way? */

2008-02-12T22:22:53Z

Distributed, shmistributed. I just want to work on the mainline or someone else's development branch. Is there no simple way?

← Older revision		Revision as of 18:22, 12 February 2008
Line 37:		Line 37:
	There is. You can use bzr in a mode where it behaves like SVN; in this mode, you store no local history, and all operations like commits and log queries go to the remote server. Fetching a local copy of a branch in this way is called a "checkout". Just do		There is. You can use bzr in a mode where it behaves like SVN; in this mode, you store no local history, and all operations like commits and log queries go to the remote server. Fetching a local copy of a branch in this way is called a "checkout". Just do
	bzr checkout <URL> --lightweight		bzr checkout <URL> --lightweight
	and then use the checkout like an SVN checkout, just replacing 'svn' with 'bzr'. ~~The only noteworthy difference is that~~ in bzr, moves are primitive operations, usable with "bzr mv a b", while in svn, copies are primitive.		and then use the checkout like an SVN checkout, just replacing 'svn' with 'bzr'. Noteworthy differences:
			* in bzr, moves are primitive operations, usable with "bzr mv a b", while in svn, copies are primitive.
			* to delete a file in svn, you need to explicitly remove it with "svn remove"; in bzr, all files deleted on the filesystem are considered deleted. Take care not to delete files from source control by accident.

	Without the --lightweight, you will fetch the complete history, and read operations on it will no longer go to the remote server. Commits will still go directly to the remote branch. There is a quirk with the launchpad bzr branches, however: directly checking out a branch via its writable URL fails, you have to do the following. Fetch the read-only URL and the writeable URL and do		Without the --lightweight, you will fetch the complete history, and read operations on it will no longer go to the remote server. Commits will still go directly to the remote branch. There is a quirk with the launchpad bzr branches, however: directly checking out a branch via its writable URL fails, you have to do the following. Fetch the read-only URL and the writeable URL and do

Z-man: /* Merging bugfixes */

2008-02-12T09:13:58Z

Merging bugfixes

← Older revision		Revision as of 05:13, 12 February 2008
Line 211:		Line 211:

	When editing the commit message, please copy the merge metainformation that you see there into the commit message. SVN does not store the metainfo, so the only way to keep it for us to read is to put it into the commit message.		When editing the commit message, please copy the merge metainformation that you see there into the commit message. SVN does not store the metainfo, so the only way to keep it for us to read is to put it into the commit message.

			== What you absolutely should NOT do ==

			Is actually an operation in SVN. You should not revert the history of a whole module, like
			svn co <svnroot>/trunk
			cd trunk
			svn rm armagetronad
			svn commit -m "destroyed"
			svn cp <svnroot>/trunk/armagetronad -r <some earlier revision> .
			svn commit -m "resurrected"

			This will alter SVN history and confuse the sync script, causing it to fail (a good thing, the alternative would be that it would merge the changes you just have reverted back into SVN in a new commit.) The same operation on subdirectories, say armagetronad/src, should be fine and safe, though.

			Likewise, you should avoid correcting mistakes in bzr using
			bzr uncommit
			bzr push --overwrite

			This has no effect unless the changes you uncommitted have not yet been synced to SVN. The changes you remove will just be recommitted from the SVN copy.

			To fix small errors, just commit a reverting change instead. For larger screwups, notify the other team members with submit access (shouting on IRC and the forum) that they should not pull in your changes or uncommit and revert them if they already did, and ask the merge manager to undo your change in bzr and SVN at the same time.

	{{Sections}} <!-- Template:Sections should be at the top of each section -->		{{Sections}} <!-- Template:Sections should be at the top of each section -->

Z-man: /* Merging back to the mainline */

2008-02-12T07:59:37Z

Merging back to the mainline

← Older revision		Revision as of 03:59, 12 February 2008
Line 160:		Line 160:
	=== Merging back to the mainline ===		=== Merging back to the mainline ===

	If it has been decided that a development branch is ready to be integrated into the mainline, get it up to date one last time:		If it has been decided that a small development branch is ready to be integrated into the mainline, get it up to date one last time:
	bzr merge		bzr merge
	bzr commit		bzr commit
	~~and~~ then push the changes back:		Then then push the changes back:
	bzr push <mainline URL>		bzr push <mainline URL>
	All the changes from your branch will appear as one huge merge in SVN.		All the changes from your branch will appear as one huge merge in SVN.

			If the branch contains many changes and/or multiple merges from the mainline, instead of the above procedure, the following slightly more complicated one is preferred, It will give the poor bzr-svn script less of a headache; it won't reshuffle the mainline history, and the script will not have to change it back.
			bzr branch <mainline URL> merge
			cd merge
			bzr merge ../<your development branch>
			(resolve conflicts)
			bzr commit
			bzr push <mainline URL>

	=== Integrating changes ===		=== Integrating changes ===

Z-man: /* Publishing */

2008-02-10T21:28:33Z

Publishing

← Older revision		Revision as of 17:28, 10 February 2008
Line 141:		Line 141:

	To publish your branch, you simply do		To publish your branch, you simply do
	bzr push <URL2>		bzr push <URL2> --remember
	from within your branch.		from within your branch. The --remember is important; in case you had pushed to somewhere else before, the next push command would go to that old location. Z-Man accidentally committed the Pig Sty Patch to the main 0.2.8 branch that way.

	To publish updates to your branch, you'll only have to do		To publish updates to your branch, you'll only have to do

Z-man: /* Merge vs. Rebase */

2008-02-10T18:50:07Z

Merge vs. Rebase

← Older revision		Revision as of 14:50, 10 February 2008
Line 109:		Line 109:

	If the bzr user had done multiple commits, they'd all be collapsed into one commit to SVN.		If the bzr user had done multiple commits, they'd all be collapsed into one commit to SVN.

			There also is a third way, but it shares mostly the disadvantages of the other two :) You can
			# get a new copy of the remote branch
			bzr branch <URL> tomerge
			cd tomerge
			# merge your changes into that branch
			bzr merge ../<your branch>
			(resolve conflicts)
			bzr commit
			# push the merge to your branch
			bzr push ../<your branch>
			# push your branch back
			cd ../<your branch>
			bzr push <URL>
			It's complicated, and the resulting commit looks pretty much exactly like the one you'll get with the other merge method.

	== Development or hack branches ==		== Development or hack branches ==

Z-man: /* What it is */

2008-02-10T16:05:02Z

What it is

← Older revision		Revision as of 12:05, 10 February 2008
Line 7:		Line 7:
	== What it is ==		== What it is ==

	Bazaar(bzr) is a distributed version control system in the spirit of arch, git, darcs or mercurial. It allows more flexible workflows than SVN, especially when contributions from outside of the core development team enter the picture.		Bazaar(bzr) is a distributed version control system in the spirit of arch, git, darcs or mercurial. It allows more flexible workflows than SVN, especially when contributions from outside of the core development team enter the picture. Bazaar allows you to keep an arbitrary number of copies of a project's code with full version history, and lets you move changes from one copy to another without going over a central server.

	== What we're doing with it ==		== What we're doing with it ==

Z-man: /* Bazaar (bzr) and how we use it */

2008-02-10T16:03:47Z

Bazaar (bzr) and how we use it

← Older revision		Revision as of 12:03, 10 February 2008
Line 1:		Line 1:
	{{Sections}} <!-- Template:Sections should be at the top of each section -->		{{Sections}} <!-- Template:Sections should be at the top of each section -->

	= Bazaar (bzr) and how we use it =		= Bazaar(bzr) and how we use it =

	This is work in progress and has not yet been approved by management. Hold your horses.		This is work in progress and has not yet been approved by management. Hold your horses.

			== What it is ==

			Bazaar(bzr) is a distributed version control system in the spirit of arch, git, darcs or mercurial. It allows more flexible workflows than SVN, especially when contributions from outside of the core development team enter the picture.

	== What we're doing with it ==		== What we're doing with it ==

Z-man at 15:59, 10 February 2008

2008-02-10T15:59:32Z

Show changes