Tim Hill wrote:
> Yes, I pretty much agree with you -- I wasn't really defending the
> "trunk" model, just noting how its viewed by Subversion. In fact, the
> lack of good merge tracking is currently a weak point in svn, though I
> understand that is being worked on.
For my own take on it all, the lifecycle is what should really
drive the strategy. There are many situations in which a
"trunk" model works best, others where trunkless works better.
As as well as situations where branching will be used
very aggressively, while others situations will shy away from
branching almost completely (and not because of lack of skill
with the tools or deficiency in the tools).
I often find that for lifecycles commonly found in internal
company applications (IT mostly) and many web based applications,
using mixed revision states makes much, much more practical
sense then using branches. Sadly, svn's ability to tag a mixed
revision is apparently somewhat lacking (cvs actually does this
better in many ways).
The problem I see is that most "best practices" documents are
written from the point of view of managing "shrink wrapped"
application development. It's rare to find discussions of other
situations in any real depth. For instance, in a shrink wrapped
application it's not unlikely that you'll be doing bug fixes
against the "1.0" product even after "3.0" has shipped. In
a web application or most internal company IT application that
just just doesn't happen and thus all the process baggage that
the "best practices" talk about can be thrown out.
But "shrink wrapped best practices" is a Golden Hammer for
many people.
-Byron
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jan 12 05:30:41 2007