David Weintraub wrote:
>On 23 May 2005 12:32:17 -0500, C. Michael Pilato <cmpilato@collab.net> wrote:
>
>
>>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.
>>
>>
>
>Yes, that's correct. However, unless the administrator is vigilant and
>checks for changes in the tag every time before it is used, it is very
>easy for this to happen.
>
Not if you configure an appropriate pre-commit hook that forbits
modifications on tags.
[...]
>>I would discourage the use of labels on anything but whole revisions.
>>
>>
>
>The drawback to this is that a label could not be used to mark what
>files were actually in a release since the label would apply to all
>files in the entire archive. If I had multiple projects in a single
>archive and I created a label REV1.2, I'd end up marking all projects
>with that label even if it doesn't apply to them. An important part of
>labeling is not just labeling what version of the files, but which
>files belong to a particular label.
>
>Plus, you have to change the Subversion archive format yet again to
>implement this feature.
>
>
We'd have to do that anyway to get what you want, but the changes for
per-revision labels would be a lot smaller. Once again, I'd like to draw
attention to my proposal from a year ago:
http://svn.haxx.se/dev/archive-2004-04/0973.shtml
>Not being able to specify what files were in a particular release is
>one of the reasons we discussed a label as being very much like a tag,
>but with a few special features:
>
>* A mklabel command does a URL copy to a special label directory much
>like a "URL copy does. It's atomic, fast, and you can specify what
>files and directories.
>
>
This gains you nothing with regard to tag copies, except the "special
label directory" thing which is agains Subversion's design principles;
in this case, the one about SVN not defining repository layout policy.
>* Subversion would understand that you cannot commit to a label
>directory any changes unless you do it via a file:// URL. This way,
>you could prevent a typical user from making any changes, yet still
>allow the administrator full control over the archive and label.
>
>
This can be acheived either via a pre-commit hook (which works today),
or with in-repository ACLs (which will be added one of these days). And
making file:// an exception would be a very bad idea indeed. The only
allowable exception should be server-side administrative tools
(svnadmin, to be precise).
>* Subversion would understand that using the --revision parameter may
>mean you're refering not to the current working directory, but to the
>file located somewhere under the special label directory.
>
>
I've yet to see someone explain how this would work in practice without
creating confusion. The --revision option defines a revision, not a
path, and an exception like this seems weird. Not just for the
command-line client, GUIs would have to deal with this inconsistency, too.
>The upside to this is that it doesn't require the Subversion archive
>format to be changed,
>
How did you arrive at that conclusion? You're special-caseing a
directory that hadn't been special-cased before.
>The third method involves properties. You could use a special property
>to mark the versions of the files you want to label with the label you
>want. Then, add a needed feature in Subverison that allows you to
>search based upon property.
>
>
Which implies a change in the database schema again.
>The plus side is that we get a very useful new feature in Subversion
>(search on property) and it doesn't involve any new data types or
>resturcturing the archive. The downside is figuring how to protect the
>label file property and labeling not necessarily being an atomic
>operation.
>
>
I see lots of problems with your proposal, and don't see a single
benefit except for some syntactic sugar on the command line, which you
can already acheive through normal shell tools.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon May 23 21:17:36 2005