What I was getting at was that for every single merge the person checking the code in would need to confirm that everything is OK. For 99% of the checkins we do here, this would be unnecessary. Hence the PITA.
I can imagine the situation where it gets automatic for a user to just press 'Are you sure' button even for the one occurrence where there may be problems.
Part of the underlying issue is that Subversion would not know that these changes are concurrent - as far as its concerned, it's just the usual sequence of update, modify, update, commit. The only thing it could do would be to flag any update that actually does something and ask for confirmation. Not something you want to do with 10's or 100's of files ('Yes to all' springs to mind, which negates any benefits of flagging up the changes)
I believe this is an underlying Subversion thing, not subclipse. In a way, it's sort of already there, because if you try and commit something that has changed in the archive, you are forced to manually do an update - perhaps this should be enough of a warning?
James
> -----Original Message-----
> From: Bonvin John [mailto:jbonvin_at_vaudoise.ch]
> Sent: 11 February 2008 11:05
> To: users_at_subclipse.tigris.org
> Subject: RE: [Subclipse-users] Prevent silent merges
>
> 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
>
>
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
Received on 2008-02-11 12:30:52 CET