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. 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
