C. Michael Pilato wrote on Fri, Oct 07, 2011 at 11:08:20 -0400: > On 10/07/2011 06:59 AM, Julian Foad wrote: > >>> I think this is an exciting feature with lots of potential but > >>> it has a lot more inherent complexity than improving 'svn mergeinfo' > >>> output. Could we split improving the output of 'svn mergeinfo' and > >>> identifying branch roots into two distinct feature branches? > > > > Splitting it wouldn't work for me, because the branch marker information > > has no purpose and no defined requirements without the mergeinfo user > > interface work; the existence and meaning of the info goes hand-in-hand > > with developing some ways in which that info can be used. > > > > When we come to integrate some of this work to trunk, by then the > > specification of the branching info will have been worked out, and so > > then it may be best to create a feature branch specifically for adding > > that (without the mergeinfo changes) if it is complex enough to be > > worthwhile doing so. > > Seems sane to me. If all you need is an property whose mere presence > matters, we can add meaning to specific values later.
Will the meaning be added before or after the code is released? There are compatiblity implications in the latter case.
