[PLUGIN] bzr changeset now support rollup changesets (and bzr send-changeset)
Martin Pool
mbp at sourcefrog.net
Thu Jun 30 03:01:44 BST 2005
On 29 Jun 2005, John A Meinel <john at arbash-meinel.com> wrote:
> Are you sure you don't want an opening line to indicate at least the
> changeset format? It could be as simple as
> # Bazaar-ng changeset v0.0.5
> Just something that both allows tracking the file version, and a line
> for us to key off of. So that if someone pipes a mail it can discard
> everything until it finds that line.
I think one line would be OK, but people might object to much more.
> >* Get the timestamp and timezone by unpacking the date header (which
> > would need to include fractional seconds to get the right XML.)
> Sure. Timezone + timestamp were for ease of coding, not because they
> were strictly necessary. Though again what about rollup changesets
> (where each entry has a different timestamp)
Sure, I can understand it would be a lot easier to write that way. The
list was more an examination of what the consequences of the model are
for sending brief email changesets.
> >* Similarly for the committer and message.
> >
> The issue here is for rollup changesets. Because conceivably each
> revision could be committed by a different person. For completeness, I
> just include all of them.
> I suppose as an optimization, we could assume they are all the same as
> the top-level, and only add in entries where it was different.
Hm, OK. It looks like at the moment you send the revision entries for
the included changesets, but not the diffs for their content, and only
the most recent message is printed at the top? That is probably what
some people want. We could change it in two directions:
When sending a rollup changeset, give the revision-ids of the included
revisions, but no more information about them. That gives the receiver
references to changesets where they don't even know the message, which
is a bit ugly.
Send all the revisions in sequence as changesets.
> >* File ids and parent ids shouldn't normally need to be transmitted: we
> > know precisely which revision this should be applied to, therefore
> > precisely which filename has what id. File-ids only need to be
> > given in the changeset for newly added files or directories.
> >
> >
> This assumes that I have exactly the same base that you need. Some
> changesets are useful outside of that. Say I have a feature that I
> developed on branch A, and we want to apply it to branch Z. We would
> need to pull in A, just to get the file ids, so that we could apply it
> against Z.
Yes.
> But maybe you don't really care about fuzzy changesets. Where they are
> not applied on exactly their parents.
I had wanted to do primarily precise application followed by merge. In
the case above I think it's reasonable to assume we can get A; or
generally that the person sending the changeset will choose a base which
is easily retrieved by the recipient.
There is a place for fuzzy application of course.
Perhaps we can reduce the amount of visible noise by putting the file-id
on the 'modified file' line?
> I just verified that the current verbose format is able to exactly
> reproduce the Revision file. You have to actually apply the changeset
> and regenerate an inventory in order to find out if the Inventory will
> match. But I think it would be possible.
> Naturally, Inventory is harder to get right than Revision, but the fact
> that serializing into a changeset, and unserializing from it yields the
> same text is a good start.
Yes, it is.
> >* To develop the code such that a particular revision or inventory
> > always produces the same tree, aside perhaps from major format
> > changes. So if we added for example properties on files to support
> > permissions or the execute bit they should not affect the XML unless
> > the file actually had properties.
> >
> Meaning if we have properties, they should not show up as empty elements
> in the XML?
They shouldn't show up unless there's something in them. Earlier
versions of bzr will never produce changesets that cause properties to
have values, and so will generate the same XML.
> If you have a version number for the changeset format, that could be
> tied to the inventory & revision xml layout.
Good point.
> I would tend to add it as:
>
> # revision: john at arbash-meinel.com-20050629065945-14a14a6514d5fa46
> # sha1: 6a0b70af88574a0e2b25388c8910a329474e982e
> # gpg signature:
> # -----BEGIN PGP SIGNATURE-----
> # Version: GnuPG v1.4.1 (GNU/Linux)
> #
> # iD8DBQFCwr6qJdeBCYSNAAMRAvS6AJ95JfFDBQqZbr/4Ly45lgWGodhzxgCgxR8L
> # Xc5aTu9MYL/6ou/yr5+8vfU=
> # =NTE3
> # -----END PGP SIGNATURE-----
That sounds good; being indented would probably save it from being
extracted by anything looking for signatures on the mail itself.
> It is long, but it would be only one line. Or maybe just
> # gpg signature:
> # iD8DBQFCwr6qJdeBCYSNAAMRAvS6AJ95JfFDBQqZbr/4Ly45lgWGodhzxgCgxR8L
> # Xc5aTu9MYL/6ou/yr5+8vfU=
> # =NTE3
That's perhaps even better.
> I don't think there are many mail transports which corrupt attachments,
> and changesets could always be done that way. I don't think it is our
> problem to make sure that sending text over email doesn't get corrupted.
I agree.
--
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20050630/8a14427f/attachment.pgp
More information about the bazaar
mailing list