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. More likely, something will be "released"
into the field, someone will realize something is wrong, the
Administrator checks, and discovers that someone had committed changes
to the tag directory. Lots of yelling and screaming ensues as the
Finger 'o Blame slowly spins round and round.
> > 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 suggest allowing the setting of multiple labels per revision.
Of course! My build #12383 will become QA's release 1.23.3 which will
released to the customer as revision 1.3 and probably sold as
WidgetSet 2005. I'd need to keep track of all of these labels. (And
while we're busy day dreaming here, why not some way to say that these
labels are actually related? Something you don't have in other version
control systems)
> 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.
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.
* 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.
* 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.
The upside to this is that it doesn't require the Subversion archive
format to be changed, and users with older Subversion clients would
still be able to access the labels. You could even access them via a
web browser if you're using httpd. You get all of the features needed
to implement labels.
The downside to this is it is much more difficult to implement and
there are questions on how would things be handled (when I do a "svn
diff -rREL1.2 foo.c", how would Subversion know where "foo.c" lives
inside the label REL1.2?). Plus, as one person pointed out, what would
happen if I did want to label everything across the archive? REV1.2
would also label the REV1.0 files (since they're stored on a label
branch. When REV1.3 comes out, REV1.2 and REV1.0 would get labeled yet
again. Someone downloading the entire archive could end up with
several hundred tetrabytes of data.
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.
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.
--
David Weintraub
qazwart@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon May 23 20:57:20 2005