On Mon, Mar 16, 2015 at 5:24 PM, Les Mikesell <lesmikesell_at_gmail.com> wrote:
> 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
> changes.
>
>
Hard to make friendly names automatically.
What I failed to mention before is that these publishes happen closer to
the leaf nodes, more like: blah/foo/bar and blah/foo/hi both get published,
but blah/foo/bye didn't get published.
Each user in the content Management System has folders that they have
access to, and they can publish any files or folders in "their area".
The problem with using switch is its hard to know where your production
branch is, and quite easy to accidentally svn update -r HEAD and
accidentally deploy things.
I'd also like to know in SVN if there are unpublished changes to a file or
folder (separate topic) which just using switch on the workspace would make
it more complicated.
> 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.
>
> I will talk with my colleague about that idea, although I think the last
time I mentioned it there was some reason why it was problematic.
--
> Les Mikesell
> lesmikesell_at_gmail.com.
Received on 2015-03-16 22:35:28 CET