Mark -
Thanks for the great suggestion. Once I read it I realized how obvious it
was and how much sense it made.
If you can humor me and give any insight into this minor change to doing
things, I'd really appreciate it.
What trouble would inexperienced developers get themselves into by doing
either of the following:
Case 1:
- Dev A finishes SCR 10 and then starts another one
- CM is busy with other stuff and doesn't merge SCR 10 to the mainline right
away
- Dev A needs the work which was done on the other SCR and so does a merge
from SCR 10 to SCR 17
- CM rolls SCR10 into the mainline
- Dev A finishes SCR17 and updates from the mainline (Could be a problem
here?)
- Dev A tells CM SCR 17 is ready to get merged to the mainline (CM might
have an issue here?)
Case 2:
- Roughly the same as above, but throw in Dev B who needs an unreleased SCR
from Dev A
It seems like the best development flow would be to keep from cross branch /
SCR merging. That would provide consistency in changes flowing 'up' from
the SCR branches and then down into newer SCR areas.
Best regards,
Aaron R>
On Sat, Aug 16, 2008 at 6:36 PM, Mark Phippard <markphip_at_gmail.com> wrote:
> On Sat, Aug 16, 2008 at 1:13 PM, Aaron R> <antamiga_at_gmail.com> wrote:
> > I was very excited about the 1.5 release, because the merge tracking will
> > help team development. Unfortunately its not the silver bullet I had
> hoped.
> >
> > Here's our current team needs-
> >
> > - a stable mainline, which should always compile and is used for weekly
> > builds
> > - the mainline can only be modified by a CM person / build manager
> > - developers have a copy of the mainline and do changes to it
> > - developers need to be able to commit changes which don't affect other
> > developers
> > - when finished with a task, the developer's code will be integrated into
> > the mainline
> >
> > To accomplish the above, the developers currently have their own dev
> areas
> > under branches. This lets a developer work their task, in isolation from
> > others, and commit code often to avoid loss in case a machine crashes.
> The
> > 1.4 release we currently use, makes trunk to dev and back merges painful.
> > 1.5 merges are almost perfect except that once a branch is merged back to
> > trunk, it should no longer be used.
> >
> > This link: http://blogs.open.collab.net/svn/2008/07/subversion-merg.html
> > suggests doing an svn delete then copy to recreate a dev work area. This
> > would work for our team, except the developer would have to wait until CM
> > did the reintegrate merge back to the trunk.
>
> I wrote the blog, and it is not so much that the branch cannot be
> reused, it is that you need to understand the limitations and problems
> in the reintegrate and merge process and build a workflow that is
> going to work for you.
>
> In your situation, couldn't you easily solve your problem by simply
> having developers create multiple branches in their work area? For
> example, instead of a structure like this:
>
> /dev-branches
> |-- Aaron
> |-- Joe
> |-- Mark
>
> Have one like this:
>
>
> /dev-branches
> |-- Aaron
> |-- Task123
> |-- Task456
> |-- Joe
> |-- TaskABC
> |-- Mark
> |-- Task124
>
> Given that in your process there is a delay from when a developer has
> a branch ready to be merged, and it actually being merged, it seems
> like this would be a better way to do it anyway as the developer can
> just keep working on the next task branch. Once their original branch
> is merged to the mainline, their next synch up merge in their task
> branch will pull in those changes.
>
>
> --
> Thanks
>
> Mark Phippard
> http://markphip.blogspot.com/
>
Received on 2008-08-19 05:11:38 CEST