> 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. Meantime further development goes
> on and developers commit more revisions:
So, at this moment you can create a branch, so you can easily control which changes
go into the release, yes? Then any subsequent changes on the trunk won't affect the branched
version, and you can control what does go into the branch
> ..
> rev 103: new feature 1
> rev 104: new feature 2
> ...
> Oops, we find a bug and this is fixed in the next revision:
> ...
> rev 105: bugfix related to "rev102" release.
> ...
> 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. At this moment I would like to create a tag, that this set of files
> is now "a release candidate". 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.
So, if the development was occuring on the trunk, merge -r 101:102 and -r 104:105 to the branch will do what you want. Again, this is better control, and it's obvious in the log when changes are going into the release candidate. I'd argue that your release canditate was back at r 102 and not now
> 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.
The revision number is the revision of the repository, not any single file.
> Ok, my point is that adding "tag" functionality will not make subversion
> dirty, but will make it better, more supporting various configuration
> management processes.
I think the functionality exists to support this example as is, IMHO
Send instant messages to your online friends http://au.messenger.yahoo.com
---------------------------------------------------------------------
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:26:40 2007