Daniel Noll wrote:
> Byron Brummer wrote:
>> 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?!"
>
> *Usually* one would do this by fixing the one file on the branch, rather
> than using the trunk for such things.
Create a branch, make one fix.
Create another branch, make a different fix.
Create another branch, make yet another fix.
Is this the pattern you're advocating? It has advantages wrt
isolation, but the overhead is huge. Additionally integration
is pushed down the road, greatly increasing the likelihood of
issues which again increases the overhead as well as risk.
Back in the real world we find that 99.9% of changes are small,
isolated, and don't mingle with other changes happening at the
same time. Branch per change or similar is to argue that you
should plan your entire process around the most unlikely of
conditions (the 0.1% of times you'll clash). -I'm speaking
with my own bias right now toward web based applications.
Again, you're in a shrinkwrap lifecycle with a traditional
process (changes grow more expensive as time goes forward,
unlike in XP). Much of the world is passing you by.
In the current setup we've worked out here (live web app,
frequent updates, fast changing priorities) we don't use a
"trunk" at all. We develop and release off cascading branches.
But that's for "major" revisions. Interm "hot fix", "point",
"bug fix", whatever you want to call them releases are (as they
must be for sanity) file by file, rev by rev, hand selected.
With a dozen QA builds a day and multiple production releases
a week, the old style "merge to an integration branch" model
just falls flat on its face: You gain no real advantage while
creating a tracking nightmare.
SVN is actually built to do this *intentionally*. But the
design they chose for it is not ideal from a functional
perspective. CVS does it far better. SVN's design however
blows CVS's away wrt performance. -It's not hard for CVS's
tagging to be so expensive as to become unusable (hours
to tag). SVN's "tags" are functionally inferior in many
ways, but regardless of the size of the repo the tag operation
is always fast (seconds). So no one has the true answer yet.
The real problem as I see is was that the original designers
of SVN simply didn't understand how CVS tagging was used in
practice. They didn't know about or understand the more
advanced use cases.
-Byron
---------------------------------------------------------------------
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:41:19 2007