Hi Bernd, On Wednesday 25 April 2007 18:45, Bernd Eilers wrote:
> > Unfortunately, SVN does not serve our (= people around ooo-build) > > needs :-( [CVS even less, of course.] > > > > What we need is a tool that allows us to have a modified codebase > > (ooo-build) while we are still able to contribute the modifications back > > to up-stream easily. Today we solve it with huge amount of patches > > (~1000), we have to create CWS'es from that, and it's becoming hard to > > manage, especially with big features like the VBA interoperability or > > cairo canvas. DSCM is so far the most suitable way these days (and git > > in particular seems to be the best). > > Well, why not just have an ooo-build ChildWorkspace which never gets > integrated as some kind of ooo-build-Release-ChildWorkspace regulary > "cwsresync" that one to newly available masterworkspaces than develop > new features on ChildWorkspaces and join in Changes from big feature > ChildWorkspaces like that cairo canvas with commands the SCM offers into > that ooo-build ChildWorkspace. Even today it´s quite easy to join > changes from one ChildWorkspace which is not yet integrated into another > one with relative simple CVS commands. The ooo-build env could provide > some tooling to do these joins. This should be doable with any kind of > SCM we´d use as we would have to adapt that CWS tooling we use above the > actual SCM of the future. So commands like cwsresync will still be there > after a switch. I'm so happy you wrote this, this is exactly what is this all about! :-) Of course we could do this - but you know how slow the resyncs are. I had a CWS where resync took 36 hours - no kidding. Here in the office, we have a build machine that is about that powerful as what CN can offer for the entire SVN with all its users. How long do you think the resync will take there locally with a tool like git that is _designed_ to do resyncs and merges quickly... One minute? Five? At most. Not mentioning that git solves conflicts much better - because it has the entire history of both branches. And another point you did - why should we "provide some tooling to do these joins" when there are tools that do it already, and do it well? > Or well even better why not just wait with releasing big features in > your builds until their ChildWorkspaces got integrated into the Master > just like anybody else does ;-) - I really did never really understand > that "special" needs of people around ooo-build completely ;-) You really want our customers to wait 2 years eg. for VBA interoperability? ;-) [And this is an example where the work is finally getting up-stream; there are more controversal changes that ended up 'wontfix' in IssueZilla because your UX team had another feeling than we ;-)] Generally it seems to me that there are people that need a fast pacing source tree, and another ones that need a conservative one. Have a look at the example of Linux kernel - Linus'es 'vanilla' kernel is the conservative one, Andrew Morton's -mm kernel tree http://en.wikipedia.org/wiki/Mm_tree is the fast pacing one; and the Linux kernel development seems to work pretty well - Linus is pulling the tested pieces from -mm and everyone is happy :-) Regards, Jan --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
