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. Meantime further development goes
on and developers commit more revisions:
...
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.
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.
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
Received on Mon Jan 22 23:17:51 2007