Hello Alex,
I’m looking at this myself right now as I’m updating references to my own projects with AutoTx. You’re correct, if every check-in is considered a version then it’s likely that there will be an explosion of the number of binaries available, but they would all be working for a given project if they compile, test and can run integration tests successfully. At least that’s the idea. Besides, if we can make it a concept; “A tag” and “A branch” etc, the system should be able to reason with it and compile only coherent trees if they exist, where each node must be tagged. I’m going to see what I can do with regards to creating a some semantics around the concept of scm/versioning/tags and then perhaps apply see if I can apply anything like it to the castle source trees. Probably, we’d like a central CI-server running lots of build-nodes from the given directed acyclic graph that makes of the dependencies which can be queried, similar to how the source-servers in the different linux distributions are set up, for people to compile their own code (their own coherent trees). Cheers, Henrik From: [email protected] [mailto:[email protected]] On Behalf Of Alex Henderson Sent: den 10 mars 2010 23:02 To: [email protected] Subject: Re: Dependency Difficulties I definitely like the idea of where an expert system could take us in this case.. this also means we could start building tools akin to apt-get for .Net libraries... allowing for operations like "update" etc. across all dependencies for your project. I do wonder how well would this scale once we start looking at a large set of interdependent projects though.. and are the impacts of things like signed/unsigned/medium trust going to produce an explosion of binaries (especially if every check-in is considered a "version")? On Thu, Mar 11, 2010 at 2:11 AM, Henrik Feldt <[email protected]> wrote: Hello everybody, I might have an idea which I have never tested but read about and discussed in depth some researchers, which could be applied to sort out the dependencies in an acceptable way. I suggest we implement an expert system <http://en.wikipedia.org/wiki/Expert_system> which is capable of interfacing the different build servers, symbol servers and source control systems. The aim of the system would be to reason about when builds are valid, concluding an “iteration” when a so called “coherent tree” is found. I’ve been talking about that tree a while now in my own thread, but the general idea is that for each project or dll that can be versioned we have a node and each node references some other node. Now, the tree is 2-dimensional initially because e.g. A 1.0 references B 1.0 and C 1.0, forming a tree rooted in A. If this tree is painted in x/y, we can put time on z, so when B is improved to version 1.1, given no changes to public interfaces or otherwise breaking changes, A can also redirect its binding to B1.1. Hence we now have a tree in one plane z=0: A1.0->B1.0 |->C1.0 And in the next plane, z=1 A1.0->B1.1 |->C1.0 Since B1.1 doesn’t incorporate changes to public APIs (and because it compiles well with A1.0 and because A1.0 together with B1.1 succeeds when doing regression/integration/unit testing), we can now say that we have two coherent trees. A person who wants to take a dependency on A1.0 would like to also download either (B1.0 OR B1.1) AND C1.0. Because of the multiple open source project a given developer intent on not re-inventing the wheel depends on, including cyclic dependencies between some (NHib/Castle-all e.g.) it can get rather hard to successfully patch together these coherent trees. In wanders argumentation and interference logic in the form of an argumentation engine tied together with an ontology for the problem domain in turn tied together by the “glue-code” that makes up the finished “expert system”. Many new words there possibly. Let me explain them: Argumentation in this case stands for the algorithms from artificial intelligence that can be used for planning and goal-oriented algorithms. Please refer to the “argumentation overview” document for an in-depth overview. In short, what argumentation does is that it takes collections of disjunctive literals and their consequents as arguments and verifies where these literals contradict or can be used to create new knowledge. It provides a mechanism to reason about complex things in fairly well halting ways (i.e. they don’t often never reach conclusions). The expert system would be programmed with a number of rules like … in order to mark a tree as coherent each project must: · Compile in release and debug · Pass all unit tests · Compile with its selected dependencies · Prioritize tagged SCM-trees (such as Castle.Core/v1.2 or AutoTx/2.0) before untagged trees Argumentation, especially the open source versions available such as ARGUGRID/MARGO <http://margo.sourceforge.net/> have better features than inference. They can also use non-monotonic reasoning and abduction, i.e. find the most likely cause of some consequent given previous history. Git, svn, hg… etc would have to be semantically (meaningfully) marked up with morphisms (mappings) between the different concepts (i.e. in svn there’s only “update” while in git there’s pull, fetch/merge, rebase, interactive merge, or comparatively svn:externals vs git submodules … etc), but also semantically marked up with what each concept means. The semantic markup is in sorts a labeling of “things”, forming a collection of descriptions of things. This is called an ontology. I’ve experimented with both ARGUGRID and Prolog that it’s been written on, actually wrote a distributed .Net/WPF<->Prolog application with Sicstus Prolog. It worked well. I think we have all the building blocks needed; · Infrastructure/glue code for the expert system: horn · ACID of the file system for avoiding bad program states (C.S.Tx) · .Net versions git and svn components · IoC/AOP/DynProx to tie components together well · Enough developer knowledge for all of these components · Enough pain felt by the open source community to try something new · An open source argumentation framework that runs on both unix and windows · Knowledge about how to create distributed systems on prolog and .net that are capable of trying a large subset of the exponential number of ways of combining the different open source projects Tell me what you think! Cheers, Henrik From: [email protected] [mailto:[email protected]] On Behalf Of Marcin Mikolajczak Sent: den 6 mars 2010 10:43 To: [email protected] Subject: Re: Dependency Difficulties Hi, I just wanted to comment on the "stepping thourgh code part". I am a member of the SymbolSource project (www.symbolsource.org) where we actually aim to support this and provide the ability to step though code of various open source projects, including Castle. This is supposed to work for both debug and release builds out of the box, provided symbol generation was enabled during compilation. This does not require any external tools to rewrite file locations, just configuring a symbol/source server in Visual Studio or other debugger. From our end what we need is just well-defined binary releases (we don't intend to chase nightly builds or similar) and corresponding source distributions (may as well be tags in SVN). If you visit our site, you'll find that we added support for Castle.Core and Castle.DynamicProxy. I will post again to officialy inform about support for Castle once we finish our investigation of the other projects' releases and to let this group know if we need any help (like enabling symbol generation) to support them. If you have any questions or suggestions, do not hesitate to contact me. Best regards, Marcin Mikołajczak Co-founder of SymbolSource.org [email protected] On Sat, Mar 6, 2010 at 9:26 AM, Julian Birch <[email protected]> wrote: Some random thoughts on the subject: * Lets say that a project (call it BritishRail)* takes three separate dependencies on other projects. * Lets say that each of these has two common versions in the wild. (Call them latest release and trunk, for the sake of argument.) * Then there's 2^3==8 combinations people could want to use for a specific version of BritishRail. * Although painful, making a build target all of them wouldn't be the end of the world. * We could publish compatibility as well. * However, all of this relies on there being a standardized way of publishing versions. All of this is okay, providing all you want to do is support binary references. However, I think that if we're really serious here, you want to support debug builds where people can actually step through the code and understand what's going on (I'm afraid that's still pretty necessary on most Alt.Net stuff just to use it .) This doesn't mean we have to support building on the local machines to be simple and out of the box (although it'd be brilliant if we could achieve that across every project). If we could build a tool that took a debug build and rewrote its file locations, that'd do the trick. As someone pointed out of Krzysztof's blog, co-operation with Jeremy Miller, who seems to be thinking about similar things right now, would be a good idea. J *It's like MonoRail, but slower and not as reliable. On 4 March 2010 21:50, Jonathon Rossi <[email protected]> wrote: On Fri, Mar 5, 2010 at 7:45 AM, Paul Cowan <[email protected]> wrote: @Michael, The trunk will never get ignored. I don't believe the solution is 100% technical. You would need buy in from all interested parties which although a nice ideal, is unlikely. I still want to know if this is a problem in java and if not, then why not. It is, but nothing like it is in .NET because they at least have some mechanism to manage dependencies. http://en.wikipedia.org/wiki/Java_Classloader#JAR_hell Cheers Paul Cowan Cutting-Edge Solutions (Scotland) http://thesoftwaresimpleton.blogspot.com/ On 4 March 2010 21:41, Michael Maddox <[email protected]> wrote: > Maybe if everyone ignored trunk builds then that would be a good thing :-) Not realistic. Patches get applied to the trunk more often than the release branch. Maybe some projects are better about applying patches to branches in addition to the trunk. Maybe some projects actually merge regularly between trunk and branches. With open source, it's hard to come to grips with the branches because they aren't centrally managed. Check-ins aren't centrally managed so people may not follow a consistent patch to branch or trunk process. I think the trunk plays an important and crucial role, but it shouldn't be the first place a new user goes (yet there is nothing to stop them). Deemphasize the trunk, yes. Ignore it, no. -Michael Maddox http://www.capprime.com/software_development_weblog/ -- You received this message because you are subscribed to the Google Groups "Castle Project Development List" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected] <mailto:castle-project-devel%[email protected]> . For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en. -- You received this message because you are subscribed to the Google Groups "Castle Project Development List" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected] <mailto:castle-project-devel%[email protected]> . For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en. -- Jono -- You received this message because you are subscribed to the Google Groups "Castle Project Development List" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected] <mailto:castle-project-devel%[email protected]> . For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en. -- You received this message because you are subscribed to the Google Groups "Castle Project Development List" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected] <mailto:castle-project-devel%[email protected]> . For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en. -- You received this message because you are subscribed to the Google Groups "Castle Project Development List" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected] <mailto:castle-project-devel%[email protected]> . For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en. -- You received this message because you are subscribed to the Google Groups "Castle Project Development List" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected] <mailto:castle-project-devel%[email protected]> . For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en. -- You received this message because you are subscribed to the Google Groups "Castle Project Development List" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en. -- You received this message because you are subscribed to the Google Groups "Castle Project Development List" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en.
