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

Re: Resolving conflicts arising from SVN merge

From: Ryan Schmidt <subversion-2007b_at_ryandesign.com>
Date: 2007-07-10 10:16:25 CEST

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

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.