Resolving conflicts arising from SVN merge

["Ferguson, Alex" <AF...@NRCan.gc.ca>]

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

Re: Resolving conflicts arising from SVN merge

[Ryan Schmidt <su...@ryandesign.com>]

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