On Sat, Mar 21, 2015 at 7:07 PM, Les Mikesell <lesmikes...@gmail.com> wrote:
> On Fri, Mar 20, 2015 at 9:14 AM, Lathan Bidwell <lat...@andrews.edu> > wrote: > > > >> >> 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. > > But what about concurrent but different change sets?. That is, how do > you handle someone who might be preparing a large set of changes that > may take some time to complete and preview, but meanwhile needs to > make some small updates to the existing content? I'd expect > something this complex to need multiple branches for development with > the changes being merged to the preview workspace. Or maybe even a > tree of external linkages with the ability to either track the HEAD of > the external parts or to be pegged to revisions as determined by the > preview results. > > Our web team has run into that a couple of times, where we are doing a site upgrade, but it has not been a big issue. Most of the time, making changes to the low level templates doesn't interfere with users editing the page content. > >> > >> 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. > > New imports or copies from branches you haven't mentioned? Imports > won't have any other ancestry. > > -- > Les Mikesell > lesmikes...@gmail.com >
