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? >>> 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 lesmikes...@gmail.com