On Sat, Mar 21, 2015 at 7:07 PM, Les Mikesell <lesmikesell_at_gmail.com> wrote:
> On Fri, Mar 20, 2015 at 9:14 AM, Lathan Bidwell <lathan_at_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
> lesmikesell_at_gmail.com
>
Received on 2015-03-23 19:30:40 CET