On Wed, Jun 26, 2013 at 10:30 AM, Michael McCandless < [email protected]> wrote:
> On Thu, Jun 13, 2013 at 11:56 AM, Michael McCandless > <[email protected]> wrote: > > On Thu, Jun 13, 2013 at 11:07 AM, Yonik Seeley <[email protected]> > wrote: > > > >> IMO, patches should normally be aimed at trunk and backported. > >> "svn merge" tends to make a mess of the target (mergeproperties > >> updated so you can't tell at a glance what files a patch actually > >> changed), and in general we've tried to keep trunk clean by merging > >> from trunk instead of to trunk. > > > > Is this really true anymore, with latest svn clients (1.7.x)? > > > > I had always assumed devs are free to merge in either direction ... > > whatever their preference is. > > As far as I can tell it's fine from SVN's standpoint to merge 4.x -> > trunk, at least using SVN 1.7. > > I just merged a few changes in that direction and I see no difference > in the number of svn props changed, vs when I commit first to trunk > and then merge to 4.x. > > So I think net/net we are free to work in whatever direction we > prefer. We shouldn't let our source control tools dictate our dev. > > One thing to think about is if you develop on trunk and forget to merge to 4.x, thats ok. the other way around is bad though, it basically creates an instant regression. So I'm a little worried about this. I think development should be against trunk!
