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