Full files in changesets?

[Aaron Bentley]

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

Michael Ellerman wrote:

>>Definitely not all changesets.  Maybe not rename changesets.  I think
>>it's the best option for changesets with binaries, though.
> 
> 
> I think the difference is that there's a standard well accepted way of sending 
> rename patches, which is admittedly verbose, but human readable and *does not 
> require bzr* to consume. Not using that format would IMHO be a bad design 
> decision.

But the other side of it is that it's significantly less human-readable.
 Often, the files that have been renamed have *also* been modified.  But
since the patch contains two complete 'before' and 'after' copies of the
file, there's no way you'll see the difference between the 'before' and
'after' versions.

I suppose this could be handled by inserting a special diff for the
renamed file:
# This is a human-readable diff of foo.c, which is renamed to bar.c
#@ -5,0 6,0 @
#- This is the old text
#+ This is the new text

> Binaries on the other hand can not be expressed using patch, so you're not 
> breaking compatibility. Although it'd be interesting to see how 
> svn/cvs/bk/etc do binary changes and whether there's any standard that's 
> useful to follow.

Sure.

> I also think if you're going to have bzr patches that can't be applied with 
> patch, you can't call them patches.

I'm happy with calling them changesets, but I think that's an
overly-narrow view of the term 'patch'.  The patches applied by World of
Warcraft or Doom or any number of programs are not unified diffs, but
they are called patches.  And certainly unified diffs were new too, once
upon a time.

> And changesets that contain a binary patch should be clearly marked as such.

Let's say 'patches that cannot be applied by diff'.  There's more than
just binaries.  There's empty directory creation.  There's permission
changes.

> As an aside, I wonder if anyone's thought of updating the patch(1) format to 
> do less verbose renames? You'd still require one copy of the full text, but 
> that's better than two.

I think once we've got a true next-generation changeset format, it makes
all kinds of sense to get it supported by patch.

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

iD8DBQFCmmto0F+nu1YWqI0RAtJrAJwOfnvT/yEouvkaE9pxKE1zWHQ09QCfWu/y
8f5Dq43gGV091HhkfRejamc=
=aDt9
-----END PGP SIGNATURE-----