Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
Oliver Giesen wrote: > The downside of this approach is that whenever I make changes to the generic > (i.e. non-customized) reports on the trunk I have to either merge those > changes to each individual branch (for those reports that are customized) or > move the customer branch tags to the new HEAD (for those without > customisations). I know that that last step is a bit of a dirty hack but > fact is that less than 10% of the reports are customized, the rest is > identical for all customers (and identical to the generic trunk reports). If > I always created branch revisions for those reports I would get a hell of a > lot of duplicated revisions. If I understood your request correctly, this > moving of the branch tag could happen automatically with your approach, no? Sort of. The branch tags would not move anywhere, but the pointer tags "on top" of them would. So in your case, you wouldn't have a branch for each customer, but this writable tag. Only when you get some customized files, you would create branch for those individual files. But as Tony suggested, the -f might work for you in this case. The only thing is that once you have checked it out with some branch, it stays there unless you take a clean checkout again. So if for example you have created a branched document, check it out, then later modify the main document so that there is no need for the branch doc, the -f scheme would not work. The writable tag would recover that situation just fine. One other situation where the -f would not be sufficient is that if you need multiple levels of branches. Again, the writable tags would handle that without a problem. Tuomas > Unfortunately the file format used for those report layouts does neither > allow for inheritance nor for conditional processing (at least not without > significantly compromising runtime performance). Also, many of the > customisations we have to do do not merge awfully well, too (but that's > really a different matter of course). > > As I said this hasn't turned into a real problem yet as the number of > customers and customisations is still quite small and we didn't have to > touch the existing reports a lot after the initial release but I think > anyone can easily imagine the management nightmare waiting to happen if > those numbers increase, which is exactly what we're expecting to happen in > the next few weeks at long last. > > Apart from the request at hand which would IMO still be a cludge (if I did > interpret it correctly that is), could anyone think of a manageable > alternative approach to this scenario? > > Cheers, > > Oliver > ---- ------------------ > JID: ogiesen at jabber.org > ICQ: 18777742 > (http://wwp.icq.com/18777742) >