On Jan 22, 2007, at 23:18, Martins Kemme wrote:
> 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.
I believe the conventional way to avoid this kind of chaos is to
start a branch for stabilization and release preparation instead of
doing everything in trunk. Have you considered that?
> 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.
I think you're stuck in a cognitive rut here. *stop thinking in terms
of individual files*. (It's difficult, I know. I've had many years
of CVS and am still using it on some projects due to inertia.)
Subversion will be far more pleasant if you can make this conceptual
leap: the object of revision control is the directory tree.
// ben
---------------------------------------------------------------------
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:39:22 2007