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/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-08-17 03:37:35 CEST