On Tue, Mar 17, 2015 at 10:58 PM, Les Mikesell <lesmikes...@gmail.com> wrote:
> On Tue, Mar 17, 2015 at 9:45 PM, Les Mikesell <lesmikes...@gmail.com> > wrote: > > Sorry - accidentally sent before finished... > > > On Tue, Mar 17, 2015 at 8:21 AM, Lathan Bidwell <lat...@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 > lesmikes...@gmail.com >