File/revision properties

[Gustavo Niemeyer]

Hi Aaron,

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

Excelent! I've looked for references in the mailing list archive
but couldn't find any. Thanks for pointing that out.

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

They're an interesting feature as well, but file properties

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

That might be a good idea. Could make easier to use bazaar-ng in
other circumstances where that makes sense (e.g. storing configuration
files). But then, it should probably store user/group as well.

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

Yes, it doesn't look hard indeed, given the (nice) way in which
revisions are currently stored.

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

There are many ways this could be represented, such as:

  <property name="bzr:message">...</property>

This is mostly about taste.

> >   - Binary files are tagged using a property (svn:mime-type)
> 
> Yes, I would like this, e.g. for merging.

Indeed! And also for avoiding diffing binaries, etc.

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

Sure.. having generic properties around doesn't mean *everything*
must be stored as properties.

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

Keywords were really important in CVS times, when files where
individually revisioned. Nowadays they seem to be mostly a matter
of taste again. In my POV, I don't really care if they exist or
not, as far as there's some way to disable them to avoid corrupting
files which should not be touched.

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

There are cases where the line end makes sense for the file format.
I don't have personal experience on those.

-- 
Gustavo Niemeyer
http://niemeyer.net