Other uses for tree versioning systems

John A Meinel john at arbash-meinel.com
Thu Jun 9 17:13:46 BST 2005


Hans Ulrich Niedermann wrote:
> Hi,
> 
> this post is to start a discussion about what bazaar-ng may do for the
> world besides just making software development easier.
> 
> On http://sourcefrog.net/weblog/software/vc/bzr/bugzilla.html, Martin
> writes that every bugzilla installation is basically a branch of the
> project proper: You install the upstream software, adapt it for your
> needs. You then continue to update the system from upstream from time
> to time, preserving your modifications.
> 
> So far, so good. But this line of reasoning doesn't consider a very
> important aspect about a software installation: Properly handling
> "real" permissions.
> 

This has been discussed several places, and you may have seen my patch
to potentially add permission handling to bzr.

However, I agree with the consensus, that this should be perfectly
possible with a plugin(s), and not require bzr core to support it. Since
it is very easy to write a plugin in python (you can dynamically load
any text file), it is simply a matter of writing the plugin correctly.

For my money, here is the basic layout: ($WD = the working directory)

	In $WD put a file ".bzrpermissions", this then becomes a version
controlled location where permissions are kept up to date. It can be an
XML file, which maps file_id => whatever set of permission bits you
like. (Note: directories also have a file_id).

These are the plugins that I see being necessary:
	An update to bzrlib.diff.compare_trees that allows for
	an external source of tree information. Right now it only
	cares about the "text_modified" bit, we really want it
	to care about more than that.

	A modified cmd_commit (this can be a plugin), which checks
	the tree for meta-information changes. Because the
	.bzrpermissions file is revision controlled, it can just
	pull that out of the basis tree, parse it, and then go
	through the rest of the tree. In my implementation, I updated
	statcache so that it would keep track of more meta-data. But
	we can just keep the .bzrpermissions file up-to-date with
	respect to the statcache.
	This might require an unversioned file, something like:
	.bzr/x-permissions-cache, this is purely an optimization,
	just like stat-cache is.

	Basically, all the cmd_commit() plugin has to do, is update
	the .bzrpermissions function before it runs the regular
	cmd_commit().

	And updated cmd_merge() which after running the regular merge,
	can do a meta-data merge. It might be possible to run before,
	but since files can be added/renamed/removed, it is probably
	best to run after. It *might* be required to run both before
	and after, but I doubt that.
	It might also be better to update bzrlib.merge.merge(), to
	call an extra function either per-updated file, or when it is
	done. Simply because pretty much all tree-changing updates
	go through merge. (branch, pull, etc all use it, even baz2bzr)

Is there anything that I'm missing? You want bzr diff/status to show you
that the meta-data has changed, you want bzr commit to record the
changes, and you want an update (bzr pull/merge) to apply the changes.

Mostly all that is required is to add a couple of hooks so that a plugin
can do the real work. But honestly, a plugin could actually supply the
updated functions as well.

	Example plugin:
	import bzrlib, bzrlib.diff, bzrlib.commands
	def mycompare_trees(old_tree, new_tree,
		want_unchanged, specific_files = None):
		pass
	bzrlib.diff.compare_trees = mycompare_trees

	class cmd_diff(bzrlib.commands.cmd_diff):
		def run(self, *args, **kwargs):
			# do something special
			super(cmd_diff, self).run(*args, **kwargs)

mycompare_trees could even use the original compare_trees if it doesn't
have to modify it in the middle. But from my understanding, it does
indeed need a modification during the middle of compare_trees(). (Which
is why I would like to see compare_trees supply a hook for per-file
non-text modifications).

John
=:->


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 251 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20050609/31c65f39/attachment.pgp 


More information about the bazaar mailing list