[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Resolving conflicts arising from SVN merge

From: Ferguson, Alex <AFerguso_at_NRCan.gc.ca>
Date: 2007-07-09 22:25:46 CEST

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

 - 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

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.