Full files in changesets?

[John A Meinel]

Aaron Bentley wrote:
> John A Meinel wrote:
> 
> 
>>>I think we could probably have an option, but default to having a rename
>>>show up as a rename, and have the 'renames:' section be incompatible
>>>with patch so that applying it with patch fails.
>>>
>>>I would also do the same thing for delete.
> 
> 
> Okay, so here's another issue: should changesets be reversible?  If you
> don't include the full text of a deleted file, they won't be.  OTOH, the
> stated purpose of a changeset is to produce a specific tree, given a
> known base.  Reversability isn't necessary for this; reversal can happen
> by doing a merge with THIS and BASE reversed.
> 

Well, from my understanding of bzr, Martin has explicitly stated that he
doesn't think changesets need to be completely reversible. Because bzr
doesn't do plain diff/patch, it is always a diff3 style. So you have to
have the base tree around to do any patching.

I really like the fact that any patch in arch is fully self contained
and reversible. But I think part of that is so that you can get a dumbfs
server.

I think there are going to be several serialization methods for storing
bzr history information. One of them is the plain-text changeset format
which we are working on right now, another might be a tarball similar to
arch, another is the working directory format.

Each one could store slightly different information, as long as with the
correct context, all information is available.

If you have this flexibility, then you could have bzr be compatible with
arch, to the point that you can have an arch archive checkout into a
bzr-style working directory.

We may not *quite* get that level of compatibility, but I can imaging
that the directory layout for a dumbfs server is going to necessarily be
much different than that of a normal bzr working directory. (I don't see
any way to get atomic commits over a remote filesystem with the revfile
format).

I think the changesets in a dumbfs system should be fully reversible,
because it allows you to not have to build history from the beginning
each time. But I don't think that the changeset that you email to
someone (who already has a valid tree) needs to be constrained to the
same verbosity.

> 
>>>I think a regular add is okay to show up as a whole bunch of lines. Do
>>>we want to be aware of "resurrection" where a file was deleted and then
>>>re-added with exactly the same contents. This may not be worth anything,
>>>but it does give a more accurate portrayal of the changes.
> 
> 
> And a different ID, I presume?  Yeah, that's a good question.  I'm
> inclined to think we want to show them, but I doubt patch would like that.
> 

Well, what would be nice is if you had a "bzr resurrect" that would
bring it back with the *same* id.

> 
>>>Also, for binary changes, are you thinking to base-64 encode them?
> 
> 
> I haven't given it serious thought, yet.  It certainly sounds reasonable.

Well, that would be my recommendation for sending something in an email.
Though emailing binary anything isn't very pretty.

What *might* be nice is if you could have the changeset generator
default to putting binary changes at the *end* of the listing, so people
don't have to wade through pages and pages of garbage, just to see the
changes they can understand.

Or possibly having some sort of MIME multi-part format, so that the
plain-text diffs can be seen, but then the binary ones can be the next
attachment, and would default to not being shown by your email reader.

To re-iterate my earlier point, the email-friendly format should be as
human readable friendly as possible. Because you are trying to convey
information to another person. If this loses things like being
reversible, that's okay, because that is what the machine-format
(project tree) is for.

As long as after I have applied your email changeset, I can later on
back it out using bzr, I don't think you need to be able to patch
--reverse it.

Does patch even delete files? If patch cannot apply the changeset, I
don't think we need to worry about it undoing it.

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/20050523/da439d41/attachment.pgp