Re: Mnemomic names for revisions

On 5/14/05, Dirk Schenkewitz <schenkewitz@docomolab-euro.com> wrote:
> >>Many times, I've done a build, completed the build, and then have a
> >>developer announce they forgot to include a small change in a file.
> >>The choice is either going through a whole new release and label
> >>process and thus generating another label, or modifying the label to
> >>include this one change.
>
> ... 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.

But there are times right after I do a build that we realize that we
forgot to add a file. It could be during my sanity testing that I
discover a developer forgot to give me the update to a particular
configuration file, or that the developer asked me during the build
process if they could include a new file.

In a perfect world, I would simply insist that the change would have
to wait for the next build. However, after analyzing the change, I
might realize that it could be added into the current build for the
developers' system testing. I guess I could create a new daily build
label, but that might mean some confusion which is the build that is
suppose to be tested.

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.

Don't think of labels as just ways of marking releases, but as ways of
creating a snapshot of your archive in time. 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).

> >>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. 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.

--
David Weintraub
qazwart@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org