the bane of all Projects is a tug-of-war on the codebase

the solution is for bob to install version control such as 
cvs/perforce/SourceSafe
which would allow merge of his and/or her codebase to trunk 
OR
someone is assigned mainline of code and someone-else assigned a branch
(this happens when core is heavily customised for a customer's needs
where the user-specific mods will be integrated by merge-branch later on)

BTW be careful to not allow (untested) deltas to overwrite 'blessed codebase'

HTH!
Martin 
______________________________________________ 
Disclaimer and confidentiality note 
This message is confidential and may be privileged. If you are not the intended 
recipient, we kindly ask you to  please inform the sender. Any unauthorised 
dissemination or copying hereof is prohibited. This message serves for 
information purposes only and shall not have any legally binding effect. Given 
that e-mails can easily be subject to manipulation, we can not accept any 
liability for the content provided.






> From: tre...@vocaro.com
> To: users@maven.apache.org
> Subject: Possible problem when multiple developers depend on SNAPSHOT versions
> Date: Wed, 25 Mar 2009 15:10:47 -0400
> 
> Consider this scenario:
> 
> Alice and Bob are working independently on two different applications,  
> AppA and AppB. Both applications depend on an in-house shared library,  
> Foo, that Alice and Bob are working on together. They have both  
> checked out Foo's trunk and are regularly committing changes to it.
> 
> Because Foo is undergoing heavy development, AppA and AppB depend on  
> Foo 2.1-SNAPSHOT, but now Foo is looking pretty stable, and Alice's  
> AppA needs some of the features scheduled for Foo 2.2, so she decides  
> to perform a release of Foo 2.1 and does the usual release procedure:
> 
> 1) Changes Foo's version from 2.1-SNAPSHOT to 2.1 and checks it into  
> the trunk
> 2) Deploys Foo 2.1 to the company's internal repository
> 3) Tags the Foo trunk as the 2.1 release branch
> 4) Changes Foo's version from 2.1 to 2.2-SNAPSHOT and checks it into  
> the trunk
> 5) Changes AppA's dependency to point to Foo 2.2-SNAPSHOT
> 
> But what about Bob? He's still working with Foo 2.1-SNAPSHOT for his  
> AppB. If he updates his working copy of Foo's source code, any changes  
> he makes to Foo will be built as a 2.2-SNAPSHOT release, since Foo's  
> trunk is now 2.2-SNAPSHOT. This is a major problem because his AppB  
> has a dependency on 2.1-SNAPSHOT, so the next time he tests AppB, it  
> will pick up the old Foo 2.1-SNAPSHOT, ignoring any changes Bob makes  
> in Foo. He will probably waste a lot of time debugging, at least until  
> he happens to notice that Foo's version has changed.
> 
> What can be done to prevent Bob's problem?
> 
> Trevor
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 

_________________________________________________________________
HotmailĀ® is up to 70% faster. Now good news travels really fast.
http://windowslive.com/online/hotmail?ocid=TXT_TAGLM_WL_HM_70faster_032009

Reply via email to