On Mon, Mar 16, 2015 at 5:49 PM, Les Mikesell <lesmikes...@gmail.com> wrote:
> On Mon, Mar 16, 2015 at 4:33 PM, Lathan Bidwell <lat...@andrews.edu> > wrote: > > > >> > >> I usually think in revision numbers or tag names instead of pretending > >> there was only one. If, instead of tracking HEAD, you copied each > >> release to a new TAG with your own naming scheme you could just switch > >> your production workspace to that TAG instead of arranging for what > >> you want to be at the head of a branch. And as a side effect you get > >> an easily tracked name for the tag you would need to revert those > >> changes. > >> > > > > Hard to make friendly names automatically. > > 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. > They usually end up being release numbers with a base name and > major/minor components, but much more related to the release/publish > step than intermediate commits. > > > What I failed to mention before is that these publishes happen closer to > the > > leaf nodes, more like: blah/foo/bar and blah/foo/hi both get published, > but > > blah/foo/bye didn't get published. > > > > Each user in the content Management System has folders that they have > access > > to, and they can publish any files or folders in "their area". > > So, how would you track those if you wanted to revert? > By revision number pulled from svn log > > > 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. if I copy my entire 250 gig branch, is SVN going to deduplicate that internally and not need more disk? 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 > > > 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 > >
