File/revision properties

Aaron Bentley aaron.bentley at utoronto.ca
Mon Aug 15 16:40:38 BST 2005


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

Gustavo Niemeyer wrote:

> I was thinking about how hard it'd be to implement in bazaar-ng
> something close to the Subversion concept of file and revision
> properties

bzr intends to handle arbitrary file properties.  See:
http://lists.ubuntu.com/archives/bazaar-ng/2005q2/001317.html

Arbitrary revision properties have not been discussed, as far as I know.

> Having generic file and revision properties looks neat and powerful.
> A number of concepts common to revision control are handled in
> Subversion using normal properties with special meaning. For
> instance:
> 
>   - svn:executable stores a true value for tagging executable
>     files, and turns on +x in platforms that need it

There's been some discussion of how much metadata to support.  Certainly
the executible bit, but maybe it makes sense to store the whole POSIX
file mode, and only write the ux bit.

>   - Logs are revision properties (svn:log)

It would be easy to switch to such a system if it was desired.
"<revision><message..." could be considered a synonym for
bzr:revision-message

But practically speaking, we use <revision><message> because "message"
tends to be lengthy, whereas "committer" tends to be short.  Arbitrary
metadata would make it harder to use the right representation for each
property.

>   - Binary files are tagged using a property (svn:mime-type)

Yes, I would like this, e.g. for merging.

>   - Ignored patterns are properties of directories (svn:ignore)

Having a .bzrignore file makes it easier to edit, and the
ignored/unknown distinction is fairly superficial.

>   - Keywords ($Id$, etc) are replaced on demand, according to
>     the svn:keywords property.

Keywords tend to be problematic.  I'd like to see a justification for
supporting them.  Many cases for keywords can be supported by simply
causing the build system to determine the current revision ID.

>   - svn:eol-style sets the type of EOL for a given file
>     (CR, LF, CRLF, native)

This may be useful for merging, but only for native Mac text files.
DOS-style (CRLF) files can be treated as Unix (LF) files.  OTOH, it
might be sensible to simply handle all three line-ending types when
merging, so that files with mixed line-ending types work well too.

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

iD8DBQFDALd20F+nu1YWqI0RAprZAJ96Nddgxqan0vPl0EOPTcJRqizfPQCdF7JE
QXboGMT+ms4RbWh1gG4/QQQ=
=qO0h
-----END PGP SIGNATURE-----




More information about the bazaar mailing list