On 3/13/2006 5:33 AM, Ryan Schmidt wrote:
> 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
I would recommend copies rather than merges; merges are appropriate for
a branch, but not a tag. The risk is that the versions will diverge,
and never become equal again.
The only problem with copy is that svn won't copy a file on top of an
existing one, so you really want a script or alias that does something like
svn del TAG
svn cp TRUNK TAG
where TAG and TRUNK are paths to the files. If you use URLs, you get
two separate commits and have the repository in a bad state for the
short time between them; it would be better to do this in working
copies, and then commit the change at the end (probably after checking
that the new file doesn't break something), but then each person editing
needs copies of both the trunk and the stable copies, and has to
remember not to edit the stable one, etc.
>
> 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.
This is still a problem with the del/cp method, but less severe, in that
only whole files could be different. It's like a continuous series of
little nukes.
Duncan Murdoch
>
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Mar 13 13:16:57 2006