[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Re: Subversion tagging

From: Kenneth Wood <kenneth.wood_at_e2open.com>
Date: 2007-01-22 23:39:07 CET

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


I will try to provide another example where I would made use of tags,
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
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

KWW>>> r103 and r104 are "moot" in the release_branch - yes, the
KWW>>> exist since Subversion keeps a global revision number... but, the
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
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
for merged files - revision 106. Futher on, if I promote these changes
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
file every time, but I am not modifying file itself. I am only promoting
tracking status) of a particular file version.

KW>>> - Above is NOT true if you branched first instead of attempting to
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.


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

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.