On Jul 9, 2007, at 15:25, Ferguson, Alex wrote:
> 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?
I think you might be using svn correctly.
Note that Subversion still does not have a merge-tracking feature, so
Subversion will not prevent duplicate merges.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Jul 10 10:16:36 2007