Other uses for tree versioning systems

[John A Meinel]

Aaron Bentley wrote:
> John A Meinel wrote:
> | 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).
> 
> Personally, I think it's usually a bad idea to have your control files
> be revision-controlled.  Since you know what they mean, you can do a
> much better job of applying changes as part of the plugin than any
> text-based merge algorithm could do.
> 

Well, you need to have some way of getting back the metadata for
"revision-612". You certainly could store the meta-data into the
inventory XML, but that is a little bit more invasive.

I'm certainly not looking to have merge/etc work on the .bzrpermissions
file. I just want to have a version of the meta-data for each revision.


> |     And updated cmd_merge() which after running the regular merge,
> |     can do a meta-data merge.
> 
> The merge/changeset application code is already highly pluggable.  You
> just need a MyThreeWayPermissionMerge class that has an apply()
> function.  You stick that in the ChangesetEntry.metadata_change fields
> of affected entries.
> 

That seems pretty nice. But when do you "stick that in"? What actually
builds up the changeset?

Also, it seems that metadata_change should really be a list, since you
might have multiple plugins supplying different metadata. Though I guess
you have the "ApplySequence" handler, which might be just for that.
However, I think you have a bug, in that on line 1275 you have:
 return ApplySequence(old_meta, new_meta)
But your ApplySequence.__init__ function only takes 1 parameter, not 2.

It is nice to see the conflict_handler, which lets you setup how you
want to handle conflicts while merging.

I'm also looking at the code, and I see some odd things.

For instance, in ChangesetGenerator.make_basic_entry() you place a call
to self.get_paths() which makes a call to tree.readonly_path(), I assume
the tree object is a MergeTree at this time. What I find weird is that
if the id points to a directory you return "MergeTree.tempdir".

Then in ChangesetGenerator.make_entry() you do a stat on both of the
returned paths, and use that to determine if there is a meta-data
change. But since you created the file without any concern to metadata
(in readonly_path) the metadata change is always going to be bogus.

I'm thinking that we probably need a better way to generate the texts.
But I'm thinking that probably we shouldn't be dealing with paths, since
many times one side is going to be inside the revision library, and we
would rather not extract the full text of every file and put it somewhere.

Anyway, I'm trying to wrap my head around your changeset & merge code.
So far I feel like there are a few places where it is doing something
weird. Maybe you could enlighten me as to what I am missing.

John
=:->


> Aaron
-------------- 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/9ea5f448/attachment.pgp