Versioned metadata/properties/attributes on files

Bug #511657 reported by Luke-Jr on 2010-01-23
18
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Bazaar
Medium
Unassigned

Bug Description

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) wrote :

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?

Jelmer Vernooij (jelmer) on 2010-01-25
Changed in bzr:
status: New → Incomplete
Luke-Jr (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. 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.

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

Jelmer Vernooij (jelmer) wrote :

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) wrote :

> 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) wrote :

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) wrote :

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

Changed in bzr:
status: Incomplete → Expired
Luke-Jr (luke-jr) on 2011-03-19
Changed in bzr:
status: Expired → New
Martin Pool (mbp) on 2011-03-23
Changed in bzr:
status: New → Opinion
Luke-Jr (luke-jr) wrote :

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

Changed in bzr:
status: Opinion → Confirmed
Martin Pool (mbp) on 2011-03-24
Changed in bzr:
importance: Undecided → Medium
Jelmer Vernooij (jelmer) on 2017-11-09
tags: added: check-for-breezy
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers