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?
There are actually four points in time that are significant (working
backwards):
[1] The rev# of the latest stable build of the mainline branch. Call
this rev# STABLE.
[2] The rev# where the fix to "foo.c" was checked into the mainline
(that is, when the defect was marked as fixed). Call this rev# FIXED.
[3] The rev# where the last change to "foo.c" was made prior to FIXED.
Call this rev# PREFIXED.
[4] The rev# where "rel1" was branched off of the mainline. Call this
rev# REL1.
What I want to merge into the head of "rel1" is: DIFF foo.c -r
PREFIXED:FIXED. However I also need to examine DIFF foo.c -r
REL1:PREFIXED to make sure that the fix does not depend upon changes
made to foo.c between REL1 and PREFIXED. Note that I cannot take DIFF -r
PREFIXED:STABLE since other changes may have occurred in foo.c between
FIXED and STABLE (I'm assuming "rel1" has its own testing/stabilization
cycle).
How do I locate and use the various rev# values needed? STABLE is
available in the "stable" tag noted above, so that's easy (but not much
use in this scenario).
Neither FIXED not PREFIXED are available via tagging. Assuming I'm using
the recommended best practice of marking defect #s in the message log, I
will need to manually examine the log to extract the rev# from the log
messages.
REL1 is available via the --stop-on-copy switch, but this is not
available in the DIFF or MERGE commands, only LOG. So , again, I have to
do a manual scan of the log to obtain the rev#.
This is a lot of work for what is not an unusual scenario. How can it
made less manual (read: less error-prone)?
(a) I could add lots of tags. If FIXED was available as a tag, that
would work. But creating a tag for *every* defect fix seems excessive,
even if tags are cheap. And who will remember to do this? More
importantly, how do I locate PREFIXED? This is a *relative* rev# and is
conceptually related to the COMMITTED rev#, but with an arbitrary
starting point.
(b) I could create a script to do the necessary SVN LOG scan, pluck out
the rev#, and paste it into a DIFF/MERGE command. This could work for
FIXED, but not PREFIXED. And it depends upon well-formatted log file
messages, and "prayer-based parsing" common to semi-formal data sets.
(c) Use mnemonic labels for revisions, and a convention that creates a
label named "DEFECT-FIX:nnnn" for appropriate check-ins. Now FIXED is
*directly* accessible to me *and* the toolchain. This leaves PREFIXED up
in the air, however.
So, my ideal is the command:
svn diff foo.c --revision PRIOR:!DEFECT-FIX:1234
Or something like it. Here I'm using "!" to indicate a rev# expressed as
a label (insert your own syntax here), and am assuming PRIOR means "the
last time this item was changed" (like COMMITTED but relative to the
other rev#). Skipping the ugly syntax and some significant issues around
the semantics/implementation of PRIOR, I think this is a significant
improvement over manually scanning logs.
--Tim
Julian Foad wrote:
> Julian Foad wrote:
>
>> Tim Hill wrote:
>>
>>> Yes, this is certainly one way. The main objection I have to the
>>> current scheme is that tags are just a convention, and as a result
>>> the toolchain cannot use the implied REV# information directly -- it
>>> has to be manually imputed by a user and translated by him/her to a
>>> REV# for consumption by the toolchain. This makes
>>> scripting/automation difficult for some common SVN operations and
>>> adds burden to the dev process.
>>
>>
>> Please give an example (stating the desired task and showing actual
>> commands for doing it) of a situation in which the user has to do
>> this "translation".
>
>
> What I'm getting at is that a tag is not _just_ an alias for a
> revision number, and you shouldn't have to convert it to a revision
> number in order to use it in common situations. You should be able to
> specify it directly in the command - not within the "--revision"
> parameter, because it isn't just a revision, but somewhere in the
> command.
>
> For my example of where you don't have to manually convert it to a
> revision number, I'll find the difference between "foo.c" as it was at
> tag TAG1 and now:
>
> svn diff --old=$TAGS/TAG1 --new=. foo.c
>
> I'll admit again that this syntax is not quite as brief as you might
> want, but it's not grossly inappropriate either, is it? Also, I'll
> admit again that using an environment variable like that is flakey and
> not really acceptable in more complex situations, but that's
> irrelevant to the argument that the user needs to translate the tag to
> a revision number manually.
>
> - Julian
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jun 1 20:53:27 2005