My interspersed comments marked with KW>>>
-----Original Message-----
From: Martins Kemme [mailto:mkemme@ml.lv]
Sent: Monday, January 22, 2007 4:19 PM
To: users@subversion.tigris.org
Subject: Re: Subversion tagging
Hi!
I will try to provide another example where I would made use of tags,
that
are tied to particular file revision. Suppose we are doing bugfixing in
trunk/ and we are close to releasing product:
...
rev 101: bug fix
rev 102: another bug fix...
...
At this moment we decide to perform major quality assurance activites
for
revision 102 files to prepare for release.
KW>>> So, now we create a release_candiate branch to capture rev 102 and
we begin testing
Meantime further development goes
on and developers commit more revisions:
...
rev 103: new feature 1
rev 104: new feature 2
...
KW>>> and, development on the trunk has no impact on our
release_candidate branch
Oops, we find a bug and this is fixed in the next revision:
...
rev 105: bugfix related to "rev102" release.
KW>>> By branching FIRST, we fix the bug in the release_candidate
BRANCH, not on the trunk.
KW>>> when we are all done fixing bugs in the release_candidate branch,
we can merge the
KW>>> fixes to the back to the trunk.
...
Ok, now I have a release, containing everything up to revision 102 +
revision 105 changes. Revisions 103 and 104 should not be included in
this
release.
KWW>>> r103 and r104 are "moot" in the release_branch - yes, the
revisions
KWW>>> exist since Subversion keeps a global revision number... but, the
versions
KWW>>> of all the files in the release branch are identical to r102,
with only the
KWW>>> r105 bug fix
At this moment I would like to create a tag, that this set of files
is now "a release candidate".
KW>>> Not now, because you branched FIRST instead of waiting to make a
branc
KW>>> out of a hodge-podge of file verisons. All the files you need for
the release
KW>>> are in the release_candidate branch, and there is no difficulty
figuring out
KW>>> which sets of files to include.
KW>>> Once you are completely happy with the "release_candidate" branch
KW>>> you can "tag" it again to create an actual "release" branch.
The only option I have is to merge these files
to "another_release" tag branch, but sadly this will create a new
revision
for merged files - revision 106. Futher on, if I promote these changes
to
production, then merging these changes to production branch will create
again another revision for all these files.
The thing I don't like about this, is that I create a new version of
each
file every time, but I am not modifying file itself. I am only promoting
(or
tracking status) of a particular file version.
KW>>> - Above is NOT true if you branched first instead of attempting to
branch
KW>>> after additional NON-release related work has been done by other
developers on the trunk.
KW>>> BTW, none of my comments above are "Subversion" specifc - we
currently use
KW>>> ClearCase, and we do the exact same thing - create a "release
candidate" branch
KW>>> off of the trunk, do testing and final bug fixing in the branch,
and when we
KW>>> are all done, merge the fixes back to the trunk.
Ok, my point is that adding "tag" functionality will not make subversion
dirty, but will make it better, more supporting various configuration
management processes.
Martins
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Jan 22 23:40:00 2007