Victor Lowther (victor.lowt...@gmail.com) wrote: > On Thu, May 30, 2013 at 3:50 AM, Adam Spiers <aspi...@suse.com> wrote: > > Vincent Untz (vu...@suse.com) wrote: > > > Other branches that are using the sledgehammer-common/start-up.sh file > > > from crowbar master should probably be updated with commits like these > > > ones: > > > > > > > > https://github.com/crowbar/barclamp-provisioner/commit/0290fc89b4ca8d446eac9c3140247f18166fd6f1 > > > > > https://github.com/crowbar/barclamp-logging/commit/9410dd876fc7603e0ed9f34cefd78d7a4dcd4633 > > > > > > FWIW, I find it a bit confusing that sledgehammer-common/start-up.sh > > > isn't tracked in a Pebbles branch... > > > > Indeed! > > > > This is one of the things that I proposed to work on with Victor > > during my visit to Austin (i.e. changing the top-level crowbar repo to > > have the same branches as the barclamp repos). IIRC he's on board > > with the idea :-) > > Not really
OK, I guess I misunderstood our conversation in Portland then. > I despise having to maintain n copies of the build system, What do you mean by "maintain" and by "n" here, exactly? The whole point of branching for each release is to make a copy so that ongoing work on the next release doesn't destabilise the last. That's an industry-standard practice, and I don't see why it makes any less sense here. Yes, I appreciate that that means occasionally fixes to build_lib.sh etc. would have to be backported to the (n-1) release, or maybe even (n-2) but generally not to *all* n releases, and even if that was the case, git cherrypick or similar make this easy to automate. This seems *far* preferable to me than the situation we currently have where every single time we make a change to the build system, the only way we can be really sure it won't break stuff is to retest every single build from every single release going back to the beginning of time, which would be an unmanageable amount of work. What am I missing here? > and that is what doing that will currently entail. Actually we already have plenty of duplication under the releases/ hierarchy. Its symlink-based approach is essentially a poor-man's implementation of a copy-on-write scheme which git handles much better via tree objects which point to blobs. This versioning issue is precisely what modern DVCS such as git were designed to solve, so I don't understand why we should continue relying on "cp" and "ln -s" instead, which is a bit like the dark ages approach svn takes to maintaining branches in parallel trees ;-) > Rearchitecting what > repo has responsibility for what (which we will have to do in any case) in > such a way that does not result in a combinatorial explosion of > identical-execpt-for-bug-inducing-differences code is OK Agreed, I am certainly not proposing anything which would cause in such a combinatorial explosion! It sounds like we are at very least aligned on the need to split up the top level repo. I'd be interested to hear your thoughts on the best order / approach for this. _______________________________________________ Crowbar mailing list Crowbar@dell.com https://lists.us.dell.com/mailman/listinfo/crowbar For more information: http://crowbar.github.com/
