Well, at least now we can see the disconnect. People don't want to make a branch every time they are working on something for more than a day. (Default snapshot update is a day.) Making a branch is fairly tiresome, especially given the difficulty of persuading release:branch to work. The 'person' who published the snapshot is hudson, just doing its job.
If the answer is, 'always make a branch,' then that's the answer. It is not a popular answer with the developers I'm supporting. I wish there was some alternative involving controlling snapshot updates per g/a instead of per repository. --offline prevents unwanted updates, but it also prevents wanted updates of other, unmodified, things, and new dependencies. On Tue, Mar 16, 2010 at 5:54 AM, Stephen Connolly <[email protected]> wrote: > On 16 March 2010 04:25, Ron Wheeler <[email protected]> wrote: > >> Benson Margulies wrote: >> >>> I have this feeling that I'm missing something terribly obvious. >>> >>> 1: grab a tree and make some changes. >>> 2: mvn. Now you've got SNAPSHOT versions in your local repository >>> 3: someone else checks in a change and runs mvn deploy. Now the >>> snapshot repo has jars newer than the local repo. >> >> 4: run mvn and download those over top of the local mods. >>> >> > Only if you have the update rule for your snapshot repos set to check every > time. > > If you are working on a branch, then run maven in offline mode to prevent > having to worry about picking up other versions that somebody elese has > deployed > > >> >>> Without patching all the version numbers, is there a best practice or >>> standard mechanism to stay out of this pickle? >>> >>> >> What is the pickle? You have the latest version which is what you want if >> the person doing the deploy has done the deploy for a reason. >> If the version deployed is not better than the version that you have >> locally, you beat the crap out of the guy who deployed a version when they >> shouldn't have. >> >> If people deploy crap into repositories, you will have a problem >> eventually. >> If you put your version into your source management, the other person would >> have based his mods on yours or at least noticed the conflicts before he >> deployed. >> >> Collaborative software development has to be done collaboratively. >> >> Ron >> >> >> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >>> >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
