Versioned metadata/properties/attributes on files

[Luke-Jr]

Bazaar should support Subversion-style file properties. These are useful for various things, such as mimetype. It is also necessary to losslessly convert CVS and (most) Subversion repositories to Bazaar.

[Jelmer Vernooij (jelmer)]

Bazaar has rules, which provide a way to have policy for certain files in the branch - something that overlaps with file properties.

Eventually this would only be necessary for Subversion repositories with custom file properties (e.g. those with names other than svn:*)

Why is this necessary to convert CVS repositories? Does CVS have custom file properties?

[Luke-Jr (luke-jr)]

Many properties have nothing to do with VCS behaviour. For example, filesystem extended attributes and (when the user wants to version permissions) ACLs. CVS predates the whole atomic commit concept, and rather than having branch revisions, merely has file revisions; properties are needed to store the (per-file) CVS commit versions/numbers.

[Jelmer Vernooij (jelmer)]

On Mon, 2010-01-25 at 14:52 +0000, Luke-Jr wrote:
> Many properties have nothing to do with VCS behaviour. For example,
> filesystem extended attributes and (when the user wants to version
> permissions) ACLs.
I can see some argument in supporting the versioning of file system
extended attributes, which can work regardless of the VCS and can be
manipulated with existing tools. I think there are fewer arguments for
supporting them in the VCS itself, using the VCS's UI. Still, I think we
might have to limit what sort of extended attributes (perhaps based on
namespace?) for the sake of interoperability.

> CVS predates the whole atomic commit concept, and
> rather than having branch revisions, merely has file revisions;
> properties are needed to store the (per-file) CVS commit
> versions/numbers.
Bazaar works with snapshots of trees and tools exist to convert a CVS
repository from to something that matches that model and collapses the
per-file commits in CVS to Bazaar commits that affect multiple files.

Cheers,

Jelmer

[Luke-Jr (luke-jr)]

And right now such tools are forced to be lossy because Bazaar doesn't provide a place for them to store the CVS per-file version numbers.

[Jelmer Vernooij (jelmer)]

On Mon, 2010-02-08 at 21:22 +0000, Luke-Jr wrote:
> And right now such tools are forced to be lossy because Bazaar doesn't
> provide a place for them to store the CVS per-file version numbers.
Are the per-file version numbers really something that needs to be
preserved?

Alternatively these version numbers could be stored in revision
properties.

Cheers,

Jelmer

[Matthew Fuller (fullermd)]

> Are the per-file version numbers really something that needs to be
> preserved?

Yes. Projects have decades of documentation, archived discussions,
and references in the commit logs themselves, to specific versions of
files.

[Luke-Jr (luke-jr)]

For the particular case of CVS versions, it would best be file-specific and voided upon any change to the file (eg, inherited through revisions only where the file is unchanged). I suppose revision properties could be argued to be a near close-match, but still not quite as applicable as file-specific properties. But in other cases, who knows what metadata might be applicable? All modern filesystems (ext2+, NTFS, etc) support arbitrary metadata for files; it's only rational that Bazaar be *capable* of versioning this data (even if disabled by default).

Back to lossless conversion-- in my case I would feel it necessary to preserve the old data for as long as the new system cannot contain it losslessly. If I need to reprocess the new data someday (eg, converting generic cherry-picking metadata to something specific), so be it. Better than keeping the Subversion (or whatever) repository around and having to reconvert it and then rebase the commits since!

[Launchpad Janitor (janitor)]

[Expired for Bazaar because there has been no activity for 60 days.]

[Luke-Jr (luke-jr)]

There's nothing Opinion about this. It's an objectively useful feature, and also required for lossless upgrading of older systems.