Hi all
I don't understand how disactivating silent merge would be a "real PITA almost all of the time". I believe the impact would actually depend strongly on the sizes of both team and project. Actually I work in a small team on a very large project, using tools other than Java and Subversion (a language named GraphTalk which provides its own versioning tool, based on cvs so I believe). But the merge problems are similar, in that one has often to make sure that different updates made by 2 developers on a same code item (file) are coherent. Our tool considers any concurrent modifications on any code item to be a potential conflict and asks the 2nd developer to resolve the conflict before commiting his merge. And we do not find it at all cumbersome. Well, it's true that the GraphTalk notion of "code item" is more precise than the java one (in java a whole class is an item = file, whereas in GraphTalk each field or method of a class is considered an item of its own), which diminishes drastically the risk of conflicts
to appear when developers work on a same class.
I believe an option to enable or disable silent merge would be quite interesting on many projects using Subversion. At least it would give the developer the choice and the responsibility to deal preventively or not with problems arising from the silent merge feature.
I'm not fluent enough with Subversion and Subclipse to know whether it's up to Subversion or Subclipse, or both, to do something in order to provide such a feature.
Best regards,
John
Vaudoise Assurances
John Bonvin
DS - DSI - Vie
Place de Milan
CH-1001 Lausanne
Tél +41 21 618 82 38
Fax +41 21 618 83 94
mailto:jbonvin_at_vaudoise.ch
http://www.vaudoise.ch
-----Message d'origine-----
De : Hughes, James [mailto:jhughes_at_linx.co.uk]
Envoyé : lundi, 11 février 2008 11:41
À : users_at_subclipse.tigris.org
Objet : RE: [Subclipse-users] Prevent silent merges
> -----Original Message-----
> From: Miha Vitorovic [mailto:mvitorovic_at_nil.si]
> Sent: 11 February 2008 09:30
> To: users_at_subclipse.tigris.org
> Subject: Re: [Subclipse-users] Prevent silent merges
>
> "Mark Phippard" <markphip_at_gmail.com> wrote on 09.02.2008 01:48:34:
>
> > On Feb 8, 2008 4:35 PM, Chris <shef31_at_yahoo.com> wrote:
> > > We just had a disaster. Two people were working on the same file,
> making
> > > changes, and when they updated/committed, subversion did a silent
> merge
> > > of the changes. The cause a major bug which took an large
> amount of
> time
> > > to find and fix.
> > >
> > > This is obviously unacceptable. I haven't the words to
> express what
> > > a spectacularly bad design decision it was to enable
> silent merges.
> > >
> > > The correct way to handle it (and yes, I use the word "correct"
> > > deliberately) is to force a developer to review any conflicts
> manually.
> > >
> > > How can I shut down this silent merge behavior?
> >
> > I do not really understand what you are saying. If there were
> > conflicts then why was the merge silent? Conflicts have to be
> > resolved before you can commit.
>
> He is talking to about the fact that Subversion looks for
> conflict based on content (lines) not entire files. So if the
> coders were changing different parts of the same file,
> Subversion will silently merge the changes. It is the way
> Subversion works, Chris.
>
Presumably the two coders involved would have had to merge their changes
back in to the mainline - doing an update on the way. Subversion did
exactly as it says on the box - updated, commited. So one of the coders
should have been more careful when they updated to ensure that the
update didn't introduce problems. Whilst I accept that to some, this
behaviour may not be what they want, I cannot see an alternative (except
to ask for confirmation of any changes made during all update, and that
would be a real PITA almost all of the time).
Odd that it took a long time to find the problem - all the information
should have been there in the resource history.
James
This message (including any attachments) contains confidential
and/or proprietary information intended only for the addressee.
Any unauthorized disclosure, copying, distribution or reliance on
the contents of this information is strictly prohibited and may
constitute a violation of law. If you are not the intended
recipient, please notify the sender immediately by responding to
this e-mail, and delete the message from your system. If you
have any questions about this e-mail please notify the sender
immediately.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subclipse.tigris.org
For additional commands, e-mail: users-help_at_subclipse.tigris.org
_Disclaimer Vaudoise.ch________________________________________________________________
Le présent courriel, y compris les pièces jointes, s'adresse exclusivement à la (aux) personne(s) ou à la société à laquelle (auxquelles) il est destiné et peut comporter des informations confidentielles et/ou protégées par la loi. Toute divulgation, reproduction ou utilisation de ces informations est interdite et peut être illégale. Si vous n'êtes pas destinataire de ce courriel, merci de le détruire immédiatement et d'en aviser l'expéditeur.
This e-mail, including attachments, is intended for the person(s) or company named and may contain confidential and/or legally privileged information. Unauthorized disclosure, copying or use of this information may be unlawful and is prohibited. If you are not the intended recipient, please delete this message and notify the sender.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subclipse.tigris.org
For additional commands, e-mail: users-help_at_subclipse.tigris.org
Received on 2008-02-11 12:05:30 CET