On Tue, Mar 17, 2015 at 9:45 PM, Les Mikesell <lesmikesell_at_gmail.com> wrote:
Sorry - accidentally sent before finished...
> On Tue, Mar 17, 2015 at 8:21 AM, Lathan Bidwell <lathan_at_andrews.edu> wrote:
>>
>>>
>> Also, these publishes are not like putting out a full release of a software
>> package. The entire branch is a website for a university. We never publish
>> everything at the same time. So, I'm not sure how I could implement a useful
>> TAG every time someone decided to publish a subfolder or index.html file.
>>
>
> If the sections are independent subdirectories, you might want to
> manage them independently.
>>>
>
>>> > 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.
>>
>>
>> The difference is, if you publish something to the branch head, there is a
>> revision that you see in a log, and could revert.
>>
>> if my prod checkout has a bunch of folders each switched to a different
>> revision, if I lose that filesystem and have to recheck out that workspace
>> I've lost all information about what is published.
>
> Except for special cases where you've reverted that would normally be
> your latest release tag. But, with a workflow of publishing by
> tracking tags you would probably track the tag names with some
> process, maybe logging who approved it and when.
>
>> if I copy my entire 250 gig branch, is SVN going to deduplicate that
>> internally and not need more disk?
>
> Svn copies are very cheap. Probably much more so than a merge that
> ends up not being an exact copy of an ancestor revision.
>
>> Most of my publishes happen on subfolders of the full tree, so basically
>> every folder / file could have a different publsh status: incoming add,
>> incoming update, incoming delete. with different revisions.
>>
>> file trunk rev prod rev
>> /a/b/c 5000 4850 incoming update
>> /1/2/3 2000 2001 up to date
>> /x/y/z 9000 7438 incoming update
>> /x/y/z/index.html 8000 8001 up to date
So only one outstanding change (set) is possible?
>>> Do you mean diffs against trunk/HEAD? That should be the same
>>> regardless of the workspace url.
>>>
>> What I currently do is compare the rev number from the prod branch and the
>> trunk branch for an item, and if there are newer trunk revisions, then I
>> show the user that this file has incoming updates.
That would not be much different if your published copy was a tag.
>> My preview runs off my trunk branch, so when they preview they see most up
>> to date (albeit unpublished) version.
Where are the edits/commits happening? If they are not made on the
preview system, I don't think it would change much to do a merge from
trunk into the previous production workspace there, and publish by
committing to production.
--
Les Mikesell
lesmikesell_at_gmail.com
Received on 2015-03-18 04:00:05 CET