RE: [Eap-list] VSS multiple check-out integration

[North D]

Title: RE: [Eap-list] VSS multiple check-out integration

Hi Manuel.

 

I'm not sure I understand this.  It seems to me that allowing multiple checkout or denying it - consistently across the whole project - are the *only*  acceptable solutions.  Either you have concurrent development or you don't - it's not something you can mix and match.  Both approaches have their strengths and weaknesses, but you have to decide on one or the other and then stick to it.

 

With either approach, you always make sure you have the latest (stable) versions and that your code builds against them and all your tests run, then you check in your changes.  If your team is experiencing deadlocks in the development process, it sounds like they should be talking to each other a bit more - no IDE can substitute that for you.

 

Cheers,

Dan

 

-----Original Message-----
From: Manuel Laflamme [mailto:[EMAIL PROTECTED]]
Sent: 09 November 2001 15:54
To: [EMAIL PROTECTED]
Subject: RE: [Eap-list] VSS multiple check-out integration

To always allow multiple check-out or to always deny it are both unacceptable solutions. This requires human understanding and common sense to decide if this is safe or not to do it.

Preventing multiple check-out may create dead-lock in the development that obligate developers to partly release code not compatible with other classes in VSS database.

Manuel

-----Original Message-----
From: Vladimir Kondratyev [mailto:[EMAIL PROTECTED]]
Sent: Friday, November 09, 2001 5:02 AM
To: Manuel Laflamme
Subject: Re: [Eap-list] VSS multiple check-out integration

Hello Manuel,

I think VSS administrator should define whether multiple checkout are
allowed or not. In general "allow multiple checkouts" policy is good
enough for concurrent development. But if you wish to avoid
problems described below you can use exclusive checkouts.
In #515 we improved error handling when multiple checkout are not allowed.

Best regards,
  Vladimir Kondratyev
___________________________________________
IntelliJ Software, "Develop with pleasure"
http://www.intellij.com/

Thursday, November 08, 2001, 7:17:50 PM, you wrote:

ML> When a file is already checkout by someone and that a second user
ML> checkout that same file, IDEA performs the operation without
ML> notification. IDEA should advise the second user and let him decide if
ML> he want to continue or cancel the operation. This allows both
ML> programmers to discuss a concurrent development strategy (merge later,
ML> wait for check-in, etc) according modifications they have to do.

ML> Think about this possible scenario:

ML> 1. User A checkout file MyClass.java
ML> 2. User B checkout file MyClass.java in IDEA (not aware of User A
ML> modification)
ML> 3. User B check-in its modifications...
ML> 4. User A locally renames MyClass.java to NotMyClassAnymore.java
ML> 5. User A deletes MyClass.java in VSS and adds NotMyClassAnymore.java
ML> instead
ML> 6. User B modifications has been lost because User A never been aware of
ML> that modification...

ML> I understand that the delete/add operations may look strange at first
ML> glance and that a rename may be more appropriate in this case.  But when
ML> you renamed or moved multiple files locally (which happen often with a
ML> kick ass tool like IDEA!), this is very hard to remember old
ML> class/package name and mimic all these operation in VSS (and very error
ML> prone too!). Our strategy is to always perform a recursive show diff on
ML> source root and to delete locally what is not in VSS anymore and to add
ML> in it what is new locally.

ML> In conclusion, IDEA should let users decide what to do when checking out
ML> a file already checked out by another user...

ML> Manuel



***************************************************************************************
This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify [EMAIL PROTECTED] immediately.

This footnote also confirms that this email message has been swept for the
presence of computer viruses.
***************************************************************************************