On Jan 22, 2007, at 23:51, Byron Brummer wrote:
> 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.
Am I? Let me think about that.
I've got a small web project that I manage internally. It's a
collection of Schemas and documentation relating to a web service.
It's frequently updated as defects are found and features or changes
requested.
The way I currently manage it is by deploying a working copy of trunk
to the web server. Changes are generally made on short-lived feature
branches which are then merged into trunk in one transaction when
they are ready.
(The problem I can see here is Subversion's weak merging support.)
At some point in the (near) future, I'm going to have to branch this
collection because we'll need to maintain more than 1 version of the
schema hosted on the site. The problem I forsee here is, again, the
merging, but using feature branches to implement the changes should
help here especially as I'll likely be able to apply the same change
set to both branches, when needed.
The one thing I don't foresee is hacking the changes for all running
versions into the trunk at the same time and then trying to untangle
them for deployment after the fact. That does sound like a nightmare!
You are correct in that most of the other projects I work on are
rather heavy-weight. (Some are in SVN, others in CVS.) They are not
"shrink-wrapped", but they might as well be.
The one project is still very much "in development" of version 1.0,
so we're currently tagging and building directly out of trunk. Yes,
this can bring instability as unrelated changes get dragged along
with the most recent fix, though in practice this has been rare.
The other project branches after reach release and fixes are
generally merged to the branch after having been reproduced, tested
and implemented on trunk. If not reproducible on trunk, they are
fixed on the branch. This is a fairly quick process, though
generally only show-stopper fixes are pushed out immediately due to
our rather lengthy Q&A.
>
>>> 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.
This doesn't change the fact that the tree is the basic unit of
versioning in subversion.
It sounds like you find it a poor fit for your kinds of projects.
Perhaps it simply isn't the right tool. It's not like it's the only
good revision control system out there. Have you considered any others?
// ben
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Jan 23 00:23:53 2007