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

Re: Subversion tagging

From: B. Smith-Mannschott <benpsm_at_gmail.com>
Date: 2007-01-22 23:38:49 CET

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

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.