On Mon, Mar 16, 2015 at 4:33 PM, Lathan Bidwell <lat...@andrews.edu> wrote:
>
>>
>> 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.
They usually end up being release numbers with a base name and
major/minor components, but much more related to the release/publish
step than intermediate commits.
> 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".
So, how would you track those if you wanted to revert?
> 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.
It's a matter of workflow. I don't see why it isn't just as easy to
deploy by incorrectly publishing something to your branch head.
> 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.
Do you mean diffs against trunk/HEAD? That should be the same
regardless of the workspace url.
>> > 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.
I would think you would really want to preview the exact copy of what
is about to be pushed to production instead of hoping a a merge ends
up with the changes you wanted. And along those lines it is possible
to have things in your staging/preview workspace that aren't even
committed if you aren't careful about it. Copy to tag/preview
tag/switch production to tag/ is a safer approach to be sure no
uncommitted changes happen in between.
--
Les Mikesell
lesmikes...@gmail.com
