Re: Subversion "labels" vs. "tags"

Tim Hill wrote:
> ok, let's consider patch propogation. I have a mainline build ("main"
> branch) and a release branch ("rel1") that just takes bug fixes for a
> released version of the product. The mainline undergoes cycles of
> dev/test/stabilize, and at each stabilization point a "stable" tag is
> created so that the last stable build is easily accessible.
>
> A bug is found in the mainline in "foo.c". It is tracked in a defect
> tool, fixed in the mainline, checked-in, and undergoes the normal
> dev/test/stabilize process. Product support then decides that the bug is
> serious enough that it should be fixed in the "rel1" branch also, ready
> for the 1.1 release.
>
> How do I merge the fix into the "rel1" branch? Specifically, which
> revisions off the mainline do I compare to get the changes necessary to
> push into "foo.c" in the "rel1" branch?

Thanks Tim for introducing this real-world scenario!

Thinking totally outside of any specific implementation, my first
inclination is to think of a change-set or change-package that
identifies ONLY the set of files that were created/updated to make the
fix and the set of changes/revisions for each file. Those are the set of
files and file versions I want to merge to rel1.

So if a bugfix name/number can be associated with the revision that was
created when I committed the fix to the mainline (and assuming I didnt
do any intermediate "commits" while fixing the bug - which is a BIG
assumption) then I want to apply that revno to only those files that
were changed/added/removed for the bugfix.

This means a revision-alias by itself may be insufficient. The
corresponding revnum tells me the configuration of the codebase at the
time of the commit. It does not give me any easy way to distinguish the
CONTENT of the change/fix from its CONTEXT:
* The CONTENT of the change is the set of changes made to the set of
files+directories that were changed
* The CONTEXT of the change is everything that was NOT changed that was
used to build+test prior to committing my changes.

So, regardless of whether I used a "copy" or a revision-alias, I would
have to do some extra work to identify the CONTENT of the change: either
by limiting the "copy" to be only the set of files changed, or by having
a separate mechanism to know the set of files changed and then
associating it with either a copy or a revision-alias.

In general it seems it would be useful to have some auto/builtin
*qualifier* as a shorthand that could automatically compute this.
I think it would be useful to be able to say something like
REVNO[QUALIFIER], as in HEAD[changed] or HEAD[!changed] or HEAD[wildcard]

I dont particularly like the syntax in my example, but hopefully you get
the idea. And it something that might apply to both revnums and to
"copies" (tho maybe not completely for the latter).

Seems to me that regardless of whether revision-aliases are implemented,
that the ability extract content|context from an associated revno is
still pretty important.

How do I do this today in SVN? Is there a builtin, or do I have to
conjure it up on my own using various conventions and assumptions? (and
properties|comments?)

-- 
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: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org