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