Other uses for tree versioning systems

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John A Meinel wrote:
| Aaron Bentley wrote:
|>Personally, I think it's usually a bad idea to have your control files
|>be revision-controlled.
|
| 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.

My sense is that the extra metadata should be treated as data, not
files.  I'm sure there's a way we can provide for extra data to be
inserted in revisions without distorting things too seriously.

Or maybe it's versioned, but I think that will just lead to awkwardness.

| 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.

Sure.  I think this is one of the things Arch gets wrong.  Because its
metadata is versioned, the metadata has to be formatted in very specific
and unfortunate ways.  And even then, there are still issues when you
merge it.

Better to have revisions contain both files and data, where data is
updated according to its meaning.  Of course, the line between updating
data and merging files is a fuzzy one.

|>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?

Technically, merge_core.make_merge_changeset().  This takes as its input
a changeset produced by merge.generate_cset_optimized(), which in turn
calls changeset.generate_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.

Yes, I thought it was useful to separate out that rarely-used
responsibility to another object.  For instance, you can stick the
ApplySequence inside a ReverseApply to invert the meaning.

| 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.

Yes, that looks like a bug.  It's part of the changeset composition
code, though, which will probably never be used with bzr.

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

Yes, there are odd things.  This code comes from BaZing, which was my
aborted attempt to implement Martin's ideas by myself.  The fusion of
bzr and BaZing is like one of those genetically engineered goats that
produce spider silk in their milk.

| What I find weird is that
| if the id points to a directory you return "MergeTree.tempdir".

The code was written on the assumption that I would have something like
an Arch revision library to work with.  Then, it turned out there was no
revision library.  Since bzr doesn't pay attention to metadata, just
file type, I needed to return a directory, but any directory would do.

| 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.

Since bzr doesn't handle metadata at all, the bogus metadata changes are
stripped out in generate_cset_optimized.

| 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.

We do have to deal with paths, because paths are used to invoke diff,
diff3, etc.  In generate_cset_optimized, we disable extraction of every
unchanged file, so we're not extracting ludicrous numbers of files.  (As
long as you append /@, that is.)

But I agree with you-- this code should become better-integrated with
bzr than it currently is.  Statting the data should be done using the
MergeTree so that we can use the inventory metadata instead.

But for now, I'm working on
1. improving the robustness and correctness
2. getting it under test
3. using the stat cache?

| Anyway, I'm trying to wrap my head around your changeset & merge code.

Sorry it's not cleaner and clearer than it is.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCqJW90F+nu1YWqI0RAqh+AJ9+4uleNgjUq7REODo8Ajx8EFf6RQCeKuC4
PFm1SwxLqs/Y1xz6A7L2pww=
=g14d
-----END PGP SIGNATURE-----