[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: Byron Brummer <byron.brummer_at_livenation.com>
Date: 2007-01-22 23:51:16 CET

B. Smith-Mannschott wrote:
> 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?

        You're assuming a shrinkwrap lifecycle. Such a lifecycle is
        growing increasingly rare in the age of the web application.

>> 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.

        And you're stuck thinking of old, long-lived development lifecycles
        found in shrinkwrap software.

        In the Internet age it's not uncommon to have daily releases or
        even more frequent. All those heavy weight "best practice" ideas
        from the shrinkwrap lifecycle simply crash and burn at modern

        Sure, you can argue from the ivory tower that the world would be
        better off doing things the old, slow, lumbering way. But the
        rest of the world is going to wonder, "You've got a problem on your
        production system that simply updating this one file will fix,
        but you refuse to do it without also updating the rest of the
        entire tree that isn't ready for production. WTF?!"

        It's an ivory tower answer, not a practical answer. It's an out
        dated answer for a quickly increasing number of environments. "All
        or nothing" is simply not an acceptable answer.


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:52:05 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.