On Mon, Mar 16, 2015 at 4:04 PM, Lathan Bidwell <lathan_at_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
> 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:
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
> They just happen to have the same content until someone makes new changes to
> 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
Received on 2015-03-16 22:25:08 CET