On Tue, Mar 17, 2015 at 10:58 PM, Les Mikesell <lesmikesell_at_gmail.com>
wrote:
> 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?
>
a Publish action operates on 1 file or folder at once.
>
> >>> 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.
>
most of the commits are using direct repository actions. There are a couple
actions that do a sparse checkout for an action.
>
> --
> Les Mikesell
> lesmikesell_at_gmail.com
>
Received on 2015-03-20 15:15:15 CET