On 06/23/2011 10:36 AM, Michael Wild wrote: > On 06/23/2011 04:11 PM, Brad King wrote: >> We manually select topics from 'next' and merge them to 'master'. >> Only topics in master will be released. > > So, how does that work? Do you look for the merges in 'next' that you > like, and then re-merge them to 'master' directly from the topic-branch?
Yes. The complete workflow is described generically here: http://public.kitware.com/Wiki/Git/Workflow/Topic We use a "topic stage" repository to keep explicit topic branch heads that are not in all integration branches: http://public.kitware.com/Wiki/Git/Workflow/Stage CMake's topic stage is published here: http://cmake.org/stage/cmake.git The set of branches changes regularly as topics are added or finished. > Something like this? > > -- A ------------------------ I -- master > \ \ \ / > \ \ C --- D ------ G -- topic2 > \ \ \ > \ B -- D -- topic1 \ > \ \ \ > \------- F ------------H -- next Yes, exactly. > i.e. everything starts at A, 'master' and 'next' being identical. Then, > someone creates 'topic1' and merges it into 'next' (commit F). > Meanwhile, another topic, 'topic2' is created, and also merged into > 'next' (commit H). Now, 'topic1' just isn't ready, but 'topic2' is, so > it gets merged into 'master' (commmit I). Is this correct? Yes. It gets a little more complicated when there are conflicts: http://public.kitware.com/Wiki/Git/Workflow/Topic/Conflicts > Is 'next' kind of your "throw-away" integration branch? Yes. No topics are allowed to see any of the merges into next. There is even a check on the server that disallows topics (or master) to see the beginning of next. > Do you rebase it regularly onto master? So far we haven't rewritten it but the workflow allows that because nothing should be based on it. Currently we have to avoid rewriting the branch because some dashboard clients may do just "git pull" to update. Recent CTest versions do a fetch & reset so that they can handle upstream rewrites. I designed all of the above after reading about Git's own workflow: http://git.kernel.org/?p=git/git.git;a=blob;f=Documentation/howto/maintain-git.txt;hb=v1.7.5 Our "topic stage" takes the place of the maintainer's private repository. I designed it to help distribute some of the maintainer's workload among developers (and they don't even have to know; it's just part of their workflow). -Brad _______________________________________________ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers