David Weintraub wrote:
> On 5/14/05, Dirk Schenkewitz <schenkewitz@docomolab-euro.com> wrote:
>
>>... when this happens, I'd rather vote to name the bugfixed revision as
>>VERSION_1.0-bugfix_0001. If you just move the label, you might forget
>>that one of your customers received the version with the bug.
>>(This example strengthens my opinion that this kind of labels should
>>never be changed.)
>
>
> Let me clarify: Once the label is released outside of the development
> organization, it should never be changed.
> ...
Ok, I agree - as long as there is nothing "handed out", it would be
good to be able to change a label. Also in the case of a typo. But
these should be very rare cases. To rename a label should IMHO be an
admin command.
> Also, there are certain labels that move from build to build. For
> example, some people have a label of CURRENT or BLESSED pointing not
> to the latest files on the main branch (or trunk directory), but to
> the versions of the files in the latest good build.
This is a diffent case, I believe. Then again, HEAD also moves with every
new revnum, so you definitely have a point.
> Don't think of labels as just ways of marking releases, but as ways of
> creating a snapshot of your archive in time.
Isn't that exactly what tags do? That's not what I want - I rather want
to give a (symbolic/mnemonic) name to a certain svn revnum, nothing else.
> In some cases, a single
> snapshot might actually have more than a single label. There might be
> a Build Label, and Internal Release Label (for QA tracking purposes),
> a Version label (what your organization calls the release), and an
> "Official" version number (what the marketing department calls the
> release).
As you describe it, "label" seems to be just another name for "tag".
I don't see a difference. (Except that a tag cannot be used instead of
a svn revnum, but i'm not sure if you're interested in that.)
>>>>I also disagree that a label should simply be an alias to a revision
>>>>number. Imagine a repository in this setup:
>>>>
>>>>/proj1
>>>> /tags
>>>> /branches
>>>> /trunk
>>>>/proj2
>>>> /tags
>>>> /branches
>>>> /trunk
>>>>
>>>>I am doing a release for project 1 and calling it VERSION_1.0. If a
>>>>label was simply an alias to a revision number, I am applying this
>>>>label not just to project 1, but to project 2. I am also applying this
>>>>label to the tags and branches directories too.
>>
>>Exactly - that's what I think it should do: label/give-a-name-to one
>>revision number of the repository, especially *including* tags and
>>branches. Because that's what I want to know: "What was the whole thing
>>like at 'VERSION_1.0'?" If the branches were left out, I could not check
>>out the branches as they were at VERSION_1.0, same goes for the tags. Of
>>course, if there are several projects within one repository (why would
>>you want to do that? Most likely because they share some code, isn't it?),
>>then either the VERSION_1.0 should deliberately refer to all projects,
>>or you should use a label like VERSION_1.0_PR2 or such - it would still
>>apply to the whole repository, but one who is looking for PR1-revevant
>>stuff can ignore it.
>
>
> Under my scheme, you could still tag the entire repository by simply
> making a label at the root of the repository.
:-) And then the next one comes and tags the whole repository *including*
your tag of the whole repository, and another one gets the same idea, and
so on... No problem at the server at all, copies are cheap... But then
someone wants to check out the whole repository and runs out of disk
space after getting 10%...
> However, if I am
> releasing software outside of my organization, I only want to label
> what was actually released.
>
> Also, I can imagine developers creating a library of routines that
> other people could include in their code. The developer might
> "version" this library for others to use. You'd certainly don't want
> that developer marking your entire archive just to label a few dozen
> files. Plus, there's third party developers. I like marking their
> software with labels too, and I certainly don't want these labels to
> be across my entire archive.
All this sounds/looks as if it is a perfect usage case for tags.
What I (and several others, I believe) want, is different from that.
Part of what we want could perhaps be done with tags, but must likely
not all of it. I don't think of replacing the tag idea in any way,
tags are a good thing and I will continue to use them even if I had
labels (the way I want them) - then again, there are some cases where
labes would be better, but now I can only get as close as possible
using tags.
> --
> David Weintraub
> qazwart@gmail.com
Dirk
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon May 16 22:26:59 2005