On Mon, Mar 16, 2015 at 5:15 PM, <jbl...@icloud.com> wrote: > > 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> > wrote: > >> On Mon, Mar 16, 2015 at 3:16 PM, Lathan Bidwell <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 >> >> 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). >
The prod branch is only updated by copying from trunk, so they do share ancestry. I have concerns about 2 things: 1) I don't have the disk / time to download/ ... to checkout the folder I am publishing 2) If files are deleted in trunk, then trunk is merged into prod, I need to be 100% sure that a theirs-conflict will ensure that prod is the same as trunk, not that prod has some of the old version still left, files that were deleted in trunk, ....
