How to move changes from dev to live in svn

[Janine Sisk <ja...@furfly.net>]

The recent discussion of the lack of CVS-like tags made me realize  
that I actually depend on those quite a bit right now.  I am not  
looking to reopen the discussion of whether svn should have "real"  
tags or not;  that is obviously pointless.  What I do want to know is  
what the "svn way" of doing this would be:

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.

Thanks in advance,

janine

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: How to move changes from dev to live in svn

[Duncan Murdoch <mu...@stats.uwo.ca>]

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

Re: How to move changes from dev to live in svn

[Janine Sisk <ja...@furfly.net>]

On Mar 13, 2006, at 2:33 AM, Ryan Schmidt wrote:

> 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).

Ryan, how do you merge only the most critical changes without getting  
the rest of the work that's going on?  From what I can see, svn merge  
only works with revision numbers, not files, so if you like to commit  
your work periodically while it's in process, like I do, I don't see  
how you can merge only the changes you want.

This seems like it would work, but there's a lot of overhead there:

- set up main codebase in /trunk
- create three branches:  release, work, tweaks
- set up live site from release branch
- do longer term work in work branch, committing as desired
- do changes that need to go out right away to tweaks branch.  Merge  
these into the trunk and then into the work and release branches,  
update live site
- when longer term project is ready to go, merge it from work branch  
into trunk and tweaks and release branches, update live site

This seems to be the only way to have a revision to merge that  
contains only the change to be made live and nothing else.  And it  
gets worse if you work on multiple long-term projects or multiple  
tweaks at once - how many branches can one brain keep straight? :)

I realize that adopting a new tool often requires changes to the way  
one does things, but this is particularly awkward.  I am going to  
have to either stop committing any work until it's ready to be  
released, or manage an interstate highway system of branches.   
Neither seems ideal to me.  Am I misunderstanding how Subversion works?

thanks,

janine


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: How to move changes from dev to live in svn

[Ryan Schmidt <su...@ryandesign.com>]

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