I act as co-administrator on an svn-managed project with 15 developers.
We ask each developer to maintain their own private branch, and submit a
revision list to the administrator for merging onto trunk after the
requisite testing. Each developer is then responsible for
synchronizing their own branch with recent changes on trunk.
When the developer submits a revision list for inclusion onto trunk, we
ask they provide only the revisions containing their contributions (that
is, revisions that merge code from trunk are to be excluded). But
problems arise when merges from trunk to private branches create
conflicts:
- The developers resolve these conflicts and
commit the resolved code along side the revised
code from trunk
- The "resolution" (that is, the modifications
necessary to resolve the conflicted files) are
excluded from the revision list submitted to the
administrator for merging onto trunk.
- In the ensuing merge to trunk, the same conflicts
re-appear and must be resolved by the administrator.
Are we using svn correctly? Or is it better to include merges in the
list of revisions submitted for inclusion on trunk, and count on svn to
prevent duplicate merges?
Thanks in advance.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Jul 9 22:25:30 2007