> On Mar 16, 2015, at 2:04 PM, Lathan Bidwell <lat...@andrews.edu> wrote: > > > > On Mon, Mar 16, 2015 at 4:44 PM, Les Mikesell <lesmikes...@gmail.com > <mailto:lesmikes...@gmail.com>> wrote: > On Mon, Mar 16, 2015 at 3:16 PM, Lathan Bidwell <lat...@andrews.edu > <mailto:lat...@andrews.edu>> wrote: > > > >> > >> > I have a content management system running on top of SVN. My web servers > >> > run a post commit hook that does svn update off of svnlook after every > >> > commit. > >> > > >> > I currently have a "Publish" operation which I implement by doing svn > >> > delete $prod_url && svn cp $trunk_url $prod_url. (both repo urls) > >> > > >> > This causes problems because the post commit hook triggers a delete of > >> > the folder on my production web server, and then sometimes takes longer > >> > to > >> > re-download all the content (some folders have some decent media, about > >> > 15-30 gig). > > Don't you really want to just 'svn switch' your production workspace > to the new production target url instead of deleting and checking out > again? As long as the content shares ancestry it should just move the > differences. > > -- > Les Mikesell > lesmikes...@gmail.com <mailto:lesmikes...@gmail.com> > > The copy and delete is not ideal. What I am really trying to do is deploy the > version of the trunk branch to the production branch. > > I am not changing my production target url. I am trying to send new changes > from trunk to prod, while keeping trunk as a separate branch. > > Before and after a "publish" action, there will still be those 2 branches: > /trunk/blah > /prod/blah > > They just happen to have the same content until someone makes new changes to > /trunk/blah/. > > Publish should make the /prod/ be the same as the /trunk/ while keeping them > separate enough to make changes to /trunk/ and not touch /prod/ (until the > next publish). > > I need to be able to stage changes and preview them (preview server runs off > the /trunk/ branch). > > Lathan
In Git, this would involve simply moving a branch pointer to the new commit. With SVN, you only have two options: 1) merge the changes that occurred in trunk into prod, which probably could get messsy, or 2) delete prod and copy trunk to a new prod. The delete/copy is the only option you have if trunk and prod have no common ancestry. Another alternative would be to use "export" from trunk and store your production code snapshot into a tarball that is "released" and archived outside of SVN entirely. (e.g. burn to DVD).
