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