Re: Labels and Status

> There seem to be some confusion in the protocol
> description as to for what Labels are good.  At
> least the example is misleading.  A label with
> the name released is in general not useful, because
> released has the character of status and a file
> may have only one revision with the label released.
> Over the course of time several versions will be
> "released".  A better example would be the label
> release_3.1.

Agreed.

> Since there are revision control systems that support
> a status property, it would make sense to support
> it explicitly as an option.
> Status can not be implemented as a dead property for
> two reason:
>   1) a versioned resource or working resource that
>      is updated or created by a check-out request
>      should NOT inherit the value of the status
>      of the version being checked out, instead it
>      should be set to a server defined base value
>      or left empty; and
>   2) status should be changeable on a version without
>      creating a new version, similar to label.

Functionaly, labels will do it for you.
1) They are not 'inherited' by (i.e., moved to) new versions.
2) They do not require creating a new version to set or remove.

> Systems that implement both base-lines and status
> should provide a status for base-lines.  The value
> of status should be an NMTOKEN.

Baselines are versions, so they will support labels too.

Tim

Received on Friday, 2 February 2001 11:03:17 UTC