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
But only one i
>>
>>
>> > 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.
>>
> 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.
>
>>
>> >> > 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.
>
>
> You are correct in why I have not used merge for this operation before.
>
> My preview runs off my trunk branch, so when they preview they see most up
> to date (albeit unpublished) version.
>>
>>
>> --
>> Les Mikesell
>> lesmikesell_at_gmail.com
>>
>
>
Received on 2015-03-18 03:46:25 CET