Hi David!
On Mon, May 16, 2005 at 03:15:45PM -0400, David Weintraub wrote:
> Let me clarify: Once the label is released outside of the development
> organization, it should never be changed.
Right. Or more formally - once the configuration identified
by the label is "baselined", then thou shalt not change
the definition of the label:
the label must ALWAYS refer to the exact same set of
files and their version from then on. It can't refer
to version 12 of file foo.c one day, and then later
to version 13 of the same file -- once you "publish"
it, then the association between that label and the
corresponding set of files+versions is immutable and
new files/versions may not be added/removed to the
label's definition)
> 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.
Well - if it hadn't been "baselined" yet - then if
we're talking about a revision alias, I could "move"
the alias from its old revision-number to the updated
revision-number. At some later time, I would then
"lockdown" the alias (it may not move after that, at least
not without an admin explicitly unlocking it).
> 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.
The same revision-alias mechanism could implement an
intentionally floating (never baseline) "CURRENT" or
"BLESSED"" marker. That would be a "movable" alias.
> Don't think of labels as just ways of marking releases,
> but as ways of creating a snapshot of your archive in time
To me, what you just described above is different
from a revision-alias. If you are CREATING/DEFINING a
configuration/snapshot, then to me that is what I would
use an immutable "copy" to accomplish.
If what I instead what is simply an alias for an
automatically recorded snapshot, then I'd simply use
a revision-alias.
The immutable copy would be able to track version history
(for the times when it was made "mutable") and would have
a place in the file-tree under /branches or /tags.
The revision alias wouldn't track history and wouldn't have
a place in the file-tree. But I could do a query to list
all aliases, or all aliases for a revision. (admittedly,
it would be nice to know when an alias "moved" but that
would be due to versioning the alias-table, rather than
the individual alias).
The difference between the immutable copy and the
revision-alias would be sort of like the difference
between a "locked" directory and a "lockable" symlink
(but not quite exactly ;-)
--
Brad Appleton <brad@bradapp.net> www.bradapp.net
Software CM Patterns (www.scmpatterns.com)
Effective Teamwork, Practical Integration
"And miles to go before I sleep." -- Robert Frost
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed May 18 02:15:32 2005