Re: 1.2.0 tarballs up for testing/signing

David Weintraub <qazwart@gmail.com> writes:

> Once a tag is created, there is no real mechanism built into
> Subversion that protects the sanctity of that tag. A user can
> checkout the tag's directory, make modifications, then commit those
> changes. This means an admin could create a REV1.0 tag directory,
> and have users change it without the administrator's knowledge.

Well, to be clear, it may be changed in a way that doesn't draw the
administrator's attention, but not in a way that can elude an
administrator's ability to determine that change has happened.

> We also discussed several ways labels could be implemented: As a
> special property on files, as an alias to a particular revision
> number, and as a special instance of a "tag". However, we realize the
> question of how labels should be implemented is really up to the
> developers.

I would discourage the use of labels on anything but whole revisions.
I would suggest allowing the setting of multiple labels per revision.
And I would avoid using properties for the storage format -- make the
labels a first-class data object.

  - Add a new 'labels' table which maps labels to revisions

  - Possibly add a reverse mapping, though only if folks need to ask
    "What labels are associate with revision REV?"

  - Give the RA layers and repos layer a "label-to-rev" lookup
    routine.

Done deal, right?

We could probably even do this in the 1.x line, soft-upgrading
repositories to make the new table, making the new RA layer gracefully
fail when the server doesn't support the new lookup...

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon May 23 19:33:49 2005