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
- 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
- when finished with a task, the developer's code will be integrated into
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.htmlsuggests
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.
Finally, my questions to users with more experience than me. :)
- Is there a better way of accomplishing our needs?
- Do you have a team which operates similiarly? What have you found worked
- Would we run into trouble if we did the following process for completing
-- dev completes changes (all files checked in)
-- dev notifies CM to do a reintegrate merge to the mainline and provides
the repository rev #
-- before CM merges to mainline, the dev does a delete / copy / update on
-- dev starts working a new task
-- CM merges dev A's changes and some other devs.
-- dev A does a merge from the mainline, in order to get her prior task
changes and other dev's changes (i.e. resyncing to mainline)
Many many thanks ahead of time for providing your thoughts and feedback!
Received on 2008-08-16 19:13:51 CEST