On Mar 13, 2006, at 03:55, Janine Sisk wrote:
> I build websites, and constantly need to move changes from the dev
> site to the live site. The current way of doing it goes like
> this: When the changes are ready to go, I tag them with "stable".
> Then I pop over to the live site, which was checked out on the
> "stable" tag when it was first set up, and do a cvs update. This
> grabs the changes I tagged and nothing more. Note that this is not
> necessarily everything that has been committed; I might commit 10
> files but only tag 3 of them as stable. I think this is going to
> be a significant area of difference, given svn's atomic commits.
>
> Any suggestions on how to accomplish something similar in
> Subversion? I did look over the book at red-bean.com but if the
> answer is there I missed it.
One way would be to have the "trunk" where your development takes
place and then a "stable" branch, and you could merge approved
changes from trunk to stable. Merging is described here:
http://svnbook.red-bean.com/en/1.1/ch04s04.html
The problem I envision with that scenario is that it would be easy to
forget to move a change to the stable branch. Over time, I would
expect this to continue to happen, such that after some time the
trunk and the stable branch are considerably out of sync, which could
be tedious to correct. Or, it could probably be corrected by simply
nuking the stable branch and re-copying it from trunk, at some point
in time where the trunk is considered to be stable.
For our web sites, we do it differently: we currently follow the
book's release branch recommendations, where we have, say, a version
1.1 of the web site as a branch, while work continues on trunk on
what will eventually become version 1.2. The most critical changes
can get merged from trunk to the 1.1 branch right away, and a new
release of 1.1 is tagged and moved to the production web server (via
essentially an svn switch of its working copy). But eventually we
decide that what's on trunk is finished and should become the next
production release, and we make a new branch 1.2 from it, and tag a
new release from that, and move that to the production server, and
stop working on the 1.1 branch, and trunk will eventually become 1.3.
We try to create new releases at at least semi-regular intervals so
as to minimize the effect of "forgetting" to merge something from the
trunk to the current release branch: those changes will still go live
when the next release branch is made from the trunk.
I haven't decided yet if this is a good way to manage a web site. It
may not be. In our case, our web sites changes so often, and most
often the changes have to be pushed to the production server
immediately, such that most of the changes we make on trunk get
merged to the current release branch immediately, so I'm not sure if
the overhead is worth it.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Mar 13 11:35:17 2006