On Mon, Mar 16, 2015 at 4:04 PM, Lathan Bidwell <lat...@andrews.edu> wrote: > >> >> 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. >>
> 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 don't see why delete/copy in the repository is a problem. But why track the delete with a post-commit hook? > 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 I usually think in revision numbers or tag names instead of pretending there was only one. If, instead of tracking HEAD, you copied each release to a new TAG with your own naming scheme you could just switch your production workspace to that TAG instead of arranging for what you want to be at the head of a branch. And as a side effect you get an easily tracked name for the tag you would need to revert those changes. > 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). Alternatively, you could merge the trunk changes into your preview workspace and commit that to production, with the edits actually being done elsewhere. -- Les Mikesell lesmikes...@gmail.com.