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.
>>
>> 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
