[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Merge trunk and prod directories without workspace

From: Les Mikesell <lesmikesell_at_gmail.com>
Date: Mon, 16 Mar 2015 16:24:41 -0500

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

> 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
Received on 2015-03-16 22:25:08 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.