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