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

Re: Managing conflicts in a widely distributed development environment

From: Andy Levy <andy.levy_at_gmail.com>
Date: 2007-05-31 14:22:57 CEST

On 5/31/07, MikeW <mw_phil@yahoo.co.uk> wrote:
> Brad Stiles <bradstiles <at> bellsouth.net> writes:
>
> >
> > How do other distributed teams manage conflict resolution when merging
> > entire branches back to a trunk when the person(s) doing the merge may not
> > be the person(s) who originally committed the conflicting check-ins, and in
> > fact may not be familiar with the section of code where the conflict occurs?
> > ..snip
> >
> > Thanks for comments.
> > Brad
> >
> Sorry to not answer the question !
> but
> I guess a /little/ coordination between developers occasionally
> doesn't do any harm !
>
> You can't rely on the tool to eliminate all the project scheduling,
> but a little planning goes a long way.

I don't think that's not answering the question. SVN (and really, any
tool you choose) cannot solve basic communication issues (or the lack
of communication) between developers. It's simply a tool to help
manage *some* of that communication. The people working in the
repository still need to talk. Maybe merges can't be just "hey Bob,
take this and put it over here" - perhaps there needs to be an actual
conversation amongst everyone who has a merge happening "this week"
and the merge manager to make sure everything is done properly,
talking about who did what, why, what it affects, etc.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu May 31 14:44:06 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.