On Dec 16, 2009, at 2:38 PM, Brian Fox wrote: > For all the potential trouble this "enhancement" causes, does it > really have a justifiable performance boost? I mean is copying a pom > really that slow given everything else that has to happen in parallel? > > I know if I go to a folder and run mvn install, I expect THOSE EXACT > products from this build to be in my local repo regardless of what > conflicts I may have with other branches. It's not reasonable to > expect a developer to bump all their versions just because they've > made a branch, particularly if it's a short lived and not-shared with > other developers. > > I'm in favor of pulling this back or changing it to check for exact > timestamp and size.
+1 Ralph > > On Wed, Dec 9, 2009 at 10:49 AM, Dan Tran <dant...@gmail.com> wrote: >> and It is very tough or nearly impossible to ask developers 40+ to do the >> workaround below. >> >> -Dan >> >> On Wed, Dec 9, 2009 at 7:44 AM, Dan Tran <dant...@gmail.com> wrote: >>> oh mine I am so glad accidentally read this. My team doing this so >>> offen, by doing a quick branch an merge the change back >>> how ever sometimes, it would some time to start the merge. >>> >>> so there are 2 solutions: >>> >>> - change the version >>> or >>> - each branch has its own local. >>> >>> This is very annoying and confusing. And I am sure it may be chaotic >>> for some teams when starting using mvn 2.2 or 3.0 where the change >>> happens >>> >>> Please revert it, or make it an option on command line ( like -Ol etc ) >>> >>> Thanks >>> >>> 2009/12/9 Tamás Cservenák <ta...@cservenak.net>: >>>> Hi there, >>>> >>>> Just to refresh memories, there is an interesting debate going on: >>>> >>>> http://jira.codehaus.org/browse/MNG-4368 >>>> >>>> BTW, now I do realize that the issue I thought to be my problem, and is >>>> used >>>> to exchange comments are not the same.... >>>> But the problem is still a problem. >>>> >>>> Thanks, >>>> ~t~ >>>> >>>> On Mon, Dec 7, 2009 at 4:05 PM, Arnaud HERITIER <aherit...@gmail.com> >>>> wrote: >>>> >>>>> I agree to fix the behavior like you propose Paul. >>>>> It will reduce probably a little bit current performances but if it solves >>>>> the case explained by Tamas, why not ... >>>>> >>>>> >>>>> On Mon, Dec 7, 2009 at 4:01 PM, Paul Gier <pg...@redhat.com> wrote: >>>>> >>>>>> It seems that the copyFileIfModified implementation should be changed. >>>>>> Since currently it only checks if the source timestamp is newer. Maybe >>>>>> this should be changed to check for the timestamps not equal (and maybe >>>>> size >>>>>> not equal also) instead of just a newer timestamp. That would allow the >>>>>> optimization, but also handle the use case described in the jira issue. >>>>>> >>>>>> >>>>>> Tamás Cservenák wrote: >>>>>> >>>>>>> Well, how about a "feature branch" (short lived branches)? Or you modify >>>>>>> all >>>>>>> the modules to have different GAV upon branch? This is kinda nonsense to >>>>>>> me, >>>>>>> since I branch it to do some feature that I know will get back into >>>>> trunk. >>>>>>> "Renaming" (changing GAVs of modules, maybe a LOT of them) is PITA in >>>>> this >>>>>>> case, IMHO. >>>>>>> >>>>>>> But even then, I dislike very much the idea that Maven "optimizes" this, >>>>>>> and >>>>>>> does less then I tell it to do ;) >>>>>>> >>>>>>> ~t~ >>>>>>> >>>>>>> On Mon, Dec 7, 2009 at 3:18 PM, Arnaud HERITIER <aherit...@gmail.com> >>>>>>> wrote: >>>>>>> >>>>>>> You have the same version in 2 branches in a project ? >>>>>>>> For me it is a bad practice >>>>>>>> Each branch has it own version to avoid those sort of conflict. >>>>>>>> >>>>>>>> >>>>>>>> Arnaud Héritier >>>>>>>> Software Factory Manager >>>>>>>> eXo platform - http://www.exoplatform.com >>>>>>>> --- >>>>>>>> http://www.aheritier.net >>>>>>>> >>>>>>>> >>>>>>>> 2009/12/7 Tamás Cservenák <ta...@cservenak.net> >>>>>>>> >>>>>>>> Hi there, >>>>>>>>> >>>>>>>>> this is mainly about this issue: >>>>>>>>> http://jira.codehaus.org/browse/MNG-4368 >>>>>>>>> >>>>>>>>> It caused a lot of grief (and lost hours) to me, until I figured what >>>>>>>>> happens on me. >>>>>>>>> >>>>>>>>> IMHO, no "optimization" like this should be done against local >>>>>>>>> >>>>>>>> repository. >>>>>>>> >>>>>>>>> Please undo it. >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> ~t~ >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>>>> >>>>>> >>>>> >>>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
